Linker error while compiling using CLI

This morning everything was working fine and all of a sudden it throws this error as below

…/…/…/hal/src/photon/lib/STM32F2xx_Peripheral_Libraries.a(stm32f2xx_flash.o): In function FLASH_Unlock': 1> /Users/mat1/dev/spark/photon-wiced/WICED/platform/MCU/STM32F2xx/peripherals/libraries/src/stm32f2xx_flash.c:317: undefined reference to__flash_acquire’
1> …/…/…/hal/src/photon/lib/STM32F2xx_Peripheral_Libraries.a(stm32f2xx_flash.o): In function FLASH_Lock': 1> /Users/mat1/dev/spark/photon-wiced/WICED/platform/MCU/STM32F2xx/peripherals/libraries/src/stm32f2xx_flash.c:335: undefined reference to__flash_release’
1>collect2 : error : ld returned 1 exit status

What version CLI?
What is the command (parameters) you use for compiling?
What version did you use to build against?

2 Likes

What version CLI?
=> particle-cli 1.23.0
What is the command (parameters) you use for compiling?
===> particle compile photon
What version did you use to build against?
==> i am not sure how do i select the build. i always compiled the application using the above command,

Even gui based particle dev is also erroring out “compiler timed out or encountered an error”

@avenkat277, you may want to update your CLI to the latest 1.29.0. Can you post the full output of the CLI compile. I feel like something is missing.

If you don’t add the --target parameter with your compile command the build farm will always build for the default version which now was pushed up to 0.7.0. If you add --target 0.6.3 you can test if it’s an issue with 0.7.0.

particle compile photon --target 0.6.3 works well.

Can you share your code to see what “exotic” instructions may cause this linker error with 0.7.0?

no exotic code in there

#pragma PARTICLE_NO_PREPROCESSOR
#include "application.h"
typedef unsigned char uint8_t;

void setup() {
    FLASH_Unlock();
	const uint8_t *code = ((const uint8_t*)0x080064B8); //  unsure of how this address is arrived is unknown as of 10-10-16 11.48 pm	
	if (code[0] == 0xFF)
	{
		code = ((const uint8_t *)0x0800A4B8);
	}	
}

void loop()
{
while(1);
}

even the above piece of code breaks

…/…/…/hal/src/photon/lib/STM32F2xx_Peripheral_Libraries.a(stm32f2xx_flash.o): In function FLASH_Unlock': /Users/mat1/dev/spark/photon-wiced/WICED/platform/MCU/STM32F2xx/peripherals/libraries/src/stm32f2xx_flash.c:317: undefined reference to__flash_acquire’
collect2: error: ld returned 1 exit status
…/…/…/build/module.mk:222: recipe for target ‘target/workspace.elf’ failed
make[1]: Leaving directory '/firmware/modules/photon/user-part’
make[1]: *** [target/workspace.elf] Error 1
…/build/recurse.mk:11: recipe for target ‘modules/photon/user-part’ failed
make: *** [modules/photon/user-part] Error 2

Since FLASH_Unlock() isn’t really an officially documented function, one might consider it “exotic” :wink:
And the use of “undocumented” commands is always prone to the risk that these migh break one day. And as it seems this is one of these days.
Maybe @rickkas7 can confer with the engineers how to deal with this.

1 Like

ScruffR is correct, FLASH_Unlock is undocumented. It did previously work by chance because of the STM32 peripheral library.

However, I believe what happened is the flash writing code was modified to add a mutex to prevent different parts of the system firmware from writing to the flash at the same time and corrupting it. However, __flash_acquire is not exposed through the HAL to user firmware, which is why it no longer links.

I think it’s unlikely that this will be changed, since it was never really intended for user firmware to be able to write to flash, but I could be wrong about that.

3 Likes

Thanks scuff

That explains… yes it’s indeed one of those days(when you gear up for production and your build fails :frowning: )

Is there an another way or a documented function to read the photon ID code from that location ?

@avenkat277 do you mean the device ID?

https://docs.particle.io/reference/firmware/photon/#deviceid-

@peekay123
Sorry i was meaning photon softap suffix code (SYSTEM_CONFIG_SOFTAP_SUFFIX )
Looks like there is no get function for retrieving this from the core.

Is there any other way to retrieve it from the flash?

I guess you are not refering to the Spark Core which runs a STM32F1xx and does not feature SoftAP at all.

@ScruffR no am not referring that particle core…I am working with a photon device. internally we refer the system firmware as the core and just typed it like that :slight_smile:

Is there any way to read the softap_suffix?

1 Like

If you only want to read the suffix, you won’t need to unlock the flash, you can just read that address direct.

This is a simple sketch that demonstrates that

uint8_t *s1 = (uint8_t*)0x80064B8;
uint8_t *s2 = (uint8_t*)0x800A4B8;
char    suffix1[8];
char    suffix2[8];

void setup() {
    Particle.function("setSuffix", setSuffix);
}

int setSuffix(String arg) {
  String suffix = arg.substring(0,6);
  
  memset(suffix1, 0, sizeof(suffix1));
  memcpy(suffix1, s1, sizeof(suffix1)-1);

  memset(suffix2, 0, sizeof(suffix2));
  memcpy(suffix2, s2, sizeof(suffix2)-1);
  Serial.printlnf("Before: 0x%08X: %6s\r\n        0x%08X: %6s", (uint32_t)s1, suffix1, (uint32_t)s2, suffix2);


  System.set(SYSTEM_CONFIG_SOFTAP_SUFFIX, arg.substring(0,6));

  memset(suffix1, 0, sizeof(suffix1));
  memcpy(suffix1, s1, suffix.length());

  memset(suffix2, 0, sizeof(suffix2));
  memcpy(suffix2, s2, suffix.length());
  Serial.printlnf("After : 0x%08X: %6s\r\n        0x%08X: %6s", (uint32_t)s1, suffix1, (uint32_t)s2, suffix2);

  return suffix.length();
}

You can set a new suffix and will get the suffix stored in the two locations before and after the change as serial output.

@ScruffR Thanks your inputs. Early on when we started the project( 2016), I remember directly trying to read the flash and it was returning all zero’s . After i called the flash_unlock before reading it was returning the proper values and its been like that ever since.

Now, I removed that flash unlock function and was able to compile against 0.7.0. After flashing new application software, its not at all connecting to particle cloud(not seeing breathing cyan)…

Led sequence is as follows
flashing green -> fast flashing green -> flashing cyan -> two brief orange flashes -> flashing green and the cycle continues.

Once in a while when its about to start breathing cyan , it enters breathing magenta and constant magenta and reset and starts the cycle of
flashing green ->flashing cyan

Its been going on for the past 30 minutes or so.

Whats so different between 0.6.3 and v0.7.0?

It’s difficult to say what’s causing the behaviour you’re seeing, but I’d try these steps

  • make sure to install most recent CLI (currently 1.29.0)
  • clear WiFi credentials by holding SETUP for 10+ seconds till you see rapid blue flashing
  • run the following
// in DFU Mode
particle flash --usb tinker
particle update
particle flash --usb tinker
particle keys server
particle keys doctor <yourDeviceID>
// in Listening Mode
particle serial wifi
1 Like

ok finallyyyyyy…

After a long wait for approximately 1 hour, photon is back alive ( breathing cyan with 0.7.0 system firmware) and am able to read the suffix id directly from the address

Thanks for all your help @ScruffR

1 Like