I’v looked into the code and found that the system-part1 locates from address 0x08020000 to 0x0805FFFF, system-part2 locates from address 0x08060000 to 0x0809FFFF and the user-part locates from address 0x080A0000 to 0x080bFFFF. So my question is, if I change the system-part2 to locate from address 0x080A0000 to 0x080DFFFF and change the user-part to locate from address 0x080E0000 to 0x080FFFFF, will the photon still work properly? If not, what else should be changed to make it work?
I am trying to port another Broadcom wifi chip 43438 to photon, which result in the system-part1 size rising to 399 KB. So I locate the system-part1 from address 0x08020000 to 0x0809FFFF.
Regardless of whether I success or not, why it doesn’t work if I remap the memory for the firmware architecture? Is there any code snip in the firmware try refering a solid address, instead of using a symbol privided by linker script?
Yes I have modified not only the script you point out, but also any other makefiles and linker scripts reference to the firmware address. I finally built the system firmware and no error occured.
I’v tested on photon that I didn’t change the firmware for photon, including bootloader, system-part1 and system-part2, and only change the memory map as below:
After downloading the system-part1 and system-part2 via dfu-util, the Photon reset and the indicator LED show solid white and then blink red with auto-reset periodically.
And I also found that the bootloader jumps to the system-part correctly and call the function void HAL_Core_Config(void) successfully. It crashed before entering the function void application_start()
Great questions and I’m not sure of the answer. We had to work very, very hard to fit WICED into the available erase sectors in a sensible way. When some of the firmware team gets back from vacation, they might be able to answer. I do know that we use all of the flash:
I finally make it work after changing the memory map as I want. Besides that changing the files listed above, one more thing to be done is commenting the code from line 233 to line 241 as below in file firmware-develop\hal\src\stm32f2xx\core_hal_stm32f2xx.c :
/*
else if(FLASH_isUserModuleInfoValid(FLASH_INTERNAL, INTERNAL_FLASH_FAC_ADDRESS, USER_FIRMWARE_IMAGE_LOCATION))
{
//Reset and let bootloader perform the user module factory reset
//Doing this instead of calling FLASH_RestoreFromFactoryResetModuleSlot()
//saves precious system_part2 flash size i.e. fits in < 128KB
HAL_Core_Factory_Reset();`
while(1);//Device should reset before reaching this line
}
*/
This because the function FLASH_isUserModuleInfoValid(FLASH_INTERNAL, INTERNAL_FLASH_FAC_ADDRESS, USER_FIRMWARE_IMAGE_LOCATION) will access an invalid flash address.
Although making Photon work after changing the memory map, I still can’t make another Broadcom chip 43438 work. The library resources.a is replaced by copying from WICED SDK 3.3.1. After downloading system-part1 and system-part2, the target reset and the RGB LED worked weirdly. It first worked as solid white for many seconds and then blink white for many seconds, finally it worked as solid green with red pixel fading periodically.
You definitely don’t want to comment out the FLASH_isUserModuleInfoValid check! If you comment it out, you let the firmware continue with a factory reset and copy from one place in flash to another whatever arbitrary garbage is stored regardless of whether it is a well-formed firmware module. No wonder your LED is acting strange!
The linker defines lots of info about each module that gets prepended and appended to the firmware binary, including module metadata, third-party product version, and a full file CRC check. If you don’t see that data at the beginning and end, you do not have a valid firmware module.
So psyched to hear you’re working on a new board! That Broadcom chip opens up some exciting possibilities! Here are Particle we are neck deep in the Electron right now, across hardware, firmware, cloud, carrier API integrations, cellular data management in the dashboard, protocol optimizations in the device service, and mobile setup process. We don’t have bandwidth to help you port to a new chip, but I and the rest of the community here will of course help out when we know the answers to your questions. You’re diving pretty deep there moving the modules around!
