Ikea ICC-A-1 boot loader

[MattWestb]

Thanks for the repro with bootloader and NCP.

I was getting one module out of one brand new GU10 and hocked it up with blackmagic probe (esp8266 hack) and its talking with the module. Have dumped the original firmware but not yet trying erasing and loading the dumped back.

The black magick probe (GDB) only supporting elf files for loading / flashing. Its possible converting dumped bin files and loading them.

From https://github.com/zw/TRADFRI-Hacking/tree/master/hacks/L1527 : "I think gdb accepts only an ELF, not a flat binary, to flash. So, make one from the flat binary: arm-none-eabi-objcopy --input-target binary --output-target elf32-little floalt-flash-patched.bin floalt-flash-patched.elf "

I don't knowing if its possible converting the s37 bootloader or how to do it. Is it possible compiling it in bin format ? If yes then it should being easy for my to flashing to the module.

[MattWestb]

Little info of the module flash layout : https://github.com/basilfx/TRADFRI-Hacking/blob/master/FIRMWARE.md Hi have also the duped firmware : https://github.com/basilfx/TRADFRI-Hacking/tree/master/firmwares/ikea

My module its from a LED1837R5

[mtx512]

Pushed bootloader in elf and binat format (bootloader-uart-xmodem.axf/bootloader-uart-xmodem.bin) see if these are usable. Note the series 1 SOC uses a 1st stage bootloader which then invokes this bootloader. The .s37 file has both the 1st and 2nd stage bootloaders while axf/bin are just the 2nd stage hence it can be flashed to an erased chip.

The .s37 files are Motorola S-Record format.

[MattWestb]

Thanks again !! I'm being little confused of the first and second stage bootloaders ;-( Its the first bootloader in the SOC ? and if erasing all flash and flashing the converted bin file at right address its suld working booting the new bootloader ?

I was looking little on this repro: https://github.com/basilfx/TRADFRI-Hacking/blob/master/FIRMWARE.md

[mtx512]

If you erase all flash then will you lose the 1st bootloader as its also stored in flash (see below). U fortunately the 1st bootloader is also a .s37 file. So best to flash the main bootloader at the right location and see if that works.

On EFR32xG1 devices (Mighty Gecko, Flex Gecko, and Blue Gecko families), the bootloader resides in main flash. • First stage bootloader @ 0x0 • Main bootloader @ 0x800 • Application @ 0x4000

[MattWestb]

I have looking little around and its not easy erasing the flash in GDB. But its possible flashing bin(elf) files bye regions (if its only have one data block and yours have only one). So I trying flashing yours @0x800 and making one bin file with zero and flashing it @0x4000 but i must calculating the size for the "app" file. If all working well the first bootloader its not touched and can not starting the the app and starting the second bootloader. Its my thinking very wrong ??

[mtx512]

Once you have flashed the main bootloader you can use the bootloader menu to load the app via xmodem. So you only have to flash the bootloader to start with.

[MattWestb]

OK I trying flashing only the new bootloader 2 @0x800. If its working to god then the bootloader starting the app, then I flashing one zero file @0x4000. Zero file size: 0x3C000 (flash size - app start = 0x40000 - 0x4000 = 0x3C000). Its the force bootloader 2 boot from pin input working with the original Ikea bootloader 1 or is it triggered in the new bootloader 1 ? If I have understanding it right, is all versions of bootloader 1 trying starting bootloader 2 if it can not starting the app in the flash and if also bootloader 2 cant star its a faulty boot.

[mtx512]

The first stage bootloader can't be upgraded and also starts the main bootloader. In fact if you can get into the ikea main bootloader menu then it may be possible to upgrade the bootloader by sending it the gbl file.

I don't know which input pin triggers the menu for the ikea bootloader, I just set it for the main bootloader I built.

[MattWestb]

Thanks for clear answers !! I was knowing that being in the main bootloader its possible updating the app. My Blackmagic probe dont liking my at all, can reading status but getting errors (Error erasing flash with vFlashErase packet) and disconnecting the target then loading files to the flash. Have trying updating and recompiling it but not working with the ESP8266 hack. Order some new STM32F103C8T6 and making a more normal one in the end of the week.

[mtx512]

My comment was that from the ikea main bootloader you may able to upgrade to my bootloader by sending it the gbl format of the bootloader.

[MattWestb]

Gecko Bootloader v1.A.3

1. upload gbl
2. run
3. ebl info BL >

Your bootloader its flashed :-))))

I cant init xmodem upload. Have looking on the FCC papers for the module and the rx tx pins its the right. Can being that my old serial converter not doing well so must booting Lubunt and trying if its working there.

[MattWestb]

begin upload
CCCC
Serial upload complete

What its the next step ? I was trying 3 for showing info but nothing happens and 2 its the terminal ded. Reboot the GECKO = no terminal.

[mtx512]

Great you have bootloader installed, next step is send ncp-uart-sw.gbl file via xmodem. The 'upload gbl' option is waiting for a xmodem transfer to start. If you using linux can use something like minicom to send the file via xmodem.

[MattWestb]

ncp-uart-sw.gbl uploaded with minicom from lubuntu.

Next ?

[mtx512]

Connect minicomm (with -H option) to uart pins and reset, you see out hex output like below with the ncp reset.

1a c2 02 8b c2 8a 7e

If that works try connecting with Z3GatewayHost

Z3GatewayHost -b 115200 -f x -p /dev/ttyUSB0

[MattWestb]

OK I rebooting to Lubuntu and trying

[MattWestb]

Was not getting anything after restarting the module. Changing to xon/xoff Uploaded the NCP and restarting the module. Only getting some pare of 00 then connecting the power to the module(interference on the comport then applying power).

Have reading back the flash and compering with the version with only the new bootloader and mutch changes after the bootloader area so its have something in the app area. Can the first bootloader not starting the app and then not starting the main bootloader ??

[mtx512]

You can check if the main bootloader is running by setting PA00 low, it should bring up the main bootloader.

[MattWestb]

The i power on the module normal way i getting anything in the terminal, and after that putting the boot pin low i getting the main bootloader. in the terminal

[mtx512]

I have created a small test app the will set PA01 pin high, can upload that as gbl and see if the works.

[MattWestb]

That was very interesting !!!! Then the test app loaded the force bootloader pin its not working after a normal poweron. If putting PA0 low then booting its booting the main bootloader. I don't have measuring the state of PA01 but my conclusion its that test app its running as mein app. And then its also given that first bootloader can not start NCP app and instead booting the main bootloader. What version its the NCP 6.7.x or 6.6.x ?? Was reading the release notes for the 6.7 and in the next ( R23) its all devices 256 kB flash or less not longer supported, but that its next release (6.8 ?).

Next NCP with lower version ?

[mtx512]

Can you connect an LED to PA01 to verify the app is running?

The 1st stage bootloader always calls the main bootloader, its the responsibility of main bootloader to verify the app image in flash is valid and can be run. So in both cases its the main bootloader that runs the test app or ncp.

The NCP version is 6.7.6.0 , it could be possible that it can't run 32Kb, let me check the setting.

Also to verify TX pin is PC10 and RX pin is PC11.

[MattWestb]

Normal boot PA01 < 1v Force main bootloader boot > 3v Your test app its working very well !! RX and TX its working in both directions in main bootloader mode (then not possible giving upload command and the xmodem its working).

[mtx512]

Yeah what is happening is the upload command is only loading it into memory & executing not saving to flash. Hence why it works from the main bootloader. Short term fix need to flash the app @ 0x4000.

[mtx512]

Created a bootloader-uart-xmodem_storage.bin which will save the uploaded image to flash. Give it a try.

Going forward could use the external flash to save the images.

[MattWestb]

Its the way Ikea making OTA updates so sounds very likely. I'm trying it.

First flash the new BL then the load NCP from the new BL :-)

[mtx512]

First flash the new BL then the load NCP from the new BL :-)

Try test app first from new BL first.

[MattWestb]

New BL storage + test = normal boot PA01 3.2V and force bootloader only working on poweron. Force bootloader at boot = main bootloader and PA01 0V. New BL storage + NCP = normal boot its possible triggering main bootloader all time. So same function with old and new bootloader. :-(( I wos not booting lubuntu and trying minicom -H. The strange thing its that both bootloader its saving the NCP in the flash but crashing then running it. Is it too large for the flash and writing it in the emulated EEPROM or something ? One question. Is it safe writing one zero file from 0x4000 to end of flash for cleaning, or its the flash lock bits there and other things there that killing the chip if erasing it ? Is it possible making a NCP in bin format so I can converting it to elf and flashing it @ 0x4000 ?

[mtx512]

Pushed bin version, give it a go. I the meantime I will test bootloader flashing.

[MattWestb]

Done but still the same also in Lubuntu. One thing I have the new module ICC-A-1 and it can being problem with the external flash.

"The only difference I have found (so far), is that PF3 is no longer an output pin, but used to enable the SPI NOR Flash."

So it can being its not activated of the bootloader (PF3)

[mtx512]

Is there anyway for you to validate the part number is EFR32MG1P132F256GM32, normally we can do this through JLink and Simplicity Commander?

[MattWestb]

From GDB: (gdb) mon efm_info DI version 1 (silabs remix?) base 0x0fe08000 EFR32MG1P 132 F256 = Mighty Gecko 256kiB flash, 32kiB ram Device says flash page size is 2048 bytes, we're using 2048 bytes Radio si0

From Blackmagick probes source:

typedef struct efm32_device_t { uint16_t family_id; / Family for device matching / char name; / Friendly device family name / uint32_t flash_page_size; / Flash page size / uint32_t msc_addr; / MSC Address / bool has_radio; / Indicates a device has attached radio / uint32_t user_data_size; / User Data (UD) region size / uint32_t bootloader_size; / Bootloader (BL) region size (may be 0 for no BL region) / char description; / Human-readable description / } efm32_device_t;

{16, "EFR32MG1P", 2048, 0x400e0000, true, 2048, 10240, "Mighty Gecko"},

The photos of both modules (not photos my but the same model IIC-A-1): https://awesomeopensource.com/project/basilfx/TRADFRI-Hacking#pictures

I have looking under the hood and all looks 100% the same as the ICC-A-1 but cant see the ic part number then its little metal shield over the IC. My module have also the same date code 1932.

[MattWestb]

I was trying one crazy thing that no one have written that possible, loading s37 file with GDB and . . . .

(gdb) load bootloader-uart-xmodem_storage.s37 Loading section .sec1, size 0x3714 lma 0x800 Start address 0x8d0, load size 14100 Transfer rate: 22 KB/sec, 940 bytes/write.

(gdb) load ncp-uart-sw.s37 Loading section .sec1, size 0xac lma 0x4000 Loading section .sec2, size 0x30300 lma 0x4100 Start address 0x41c8, load size 197548 Transfer rate: 23 KB/sec, 968 bytes/write.

Seeing its loading with some offset and the NCP its in 2 blocks. The bad thing its like before = main boot loader its ok but app not :-(

New first bootloader in s37 formal ?

[mtx512]

You can use bootloader-uart-xmodem.s37 it already has both bootloaders.

[MattWestb]

1 Load original dumped FW with GDB 2 load bootloader-uart-xmodem.s37 GDB 3 dumping all flash. 4 compering 1 and 3 in notepad++ and can see that both arias after 0x0 and 0x800 ar updated. 5 Force staring main bootloader. 6 loading test.gbl with xmodem. 7 restarting module 8 cant connect with GDB (SW-DP scan failed!) 9 Force staring main bootloader. 10 OK connect with GDB then the module its in main bootloader. 11 dumping flash 12 compering 3 and 11 in notepad++ and can see that arias after 0x04000 ar updated.

This kombination its crashing the module so hard so its not possible connecting with SWD. Before it was only happen with the NCP as app but much softer (force bootloader was working then the app was loaded)

INTERESTING !!

And thanks for helping

Update: Flashing bootloader-uart-xmodem_storage.s37 from GDB after #12 and its normal function of the test.gbl loaded in #6. Still INTERESTING !!

What happens if i erasing the flash from GDB and loading bootloader-uart-xmodem.s37 and then bootloader-uart-xmodem_storage.s37 (before restarting the module). Is it dangerous trying that or a 110 % brick ? I have trying erase flash (GDB) and dumping it and its nearly all zeroed but leaving some small arias. And then loading the original dumped FW before resetting the module.

[MattWestb]

Was looking little on https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2018/04/18/how_to_build_thegec-CcVb

In the second part: 1 Configure the “SPI Flash” module. Set the “USART connected to SPI Flash” and GPIO for “Chip Select Pin”.

Is Ikea using the PF3 as "Hold Pin" in the new vision ? (shown in the picture under the text) ? Then Ikea using the module not only for bulbs but also for battery devices, its the external flash disabled then not needed for saving battery.

I only thinking of the strange behaviour of the storage bootloader and the normal looks working more normal.

[MattWestb]

For EZSP its the external flash is useless and its normally only user with application bootloader (as temporary OTA storage for app updating) not with the standalone bootloader. The standalone boot loader its writing direct in the flash and if the file its corrupt (falce CRC) from the transmitting/or other reasons its flags app not OK and boot back to main bootloader and waiting for new xmodem upload. I can applying the storage bootloader on the original firmware and and it booting and working well also the main boot loader, but the original firmware dont like main bootloader without external flash storage (Its very logick its hard coded in the firmware and must being present).

One experiment: 1 Erace mass storage in GDB. 2 Load bootloader-uart-xmodem.s37 in GDB. 3 Reboot (don't need force bootloader pin, then its no OK app in flash) and landing in the main bootloader. 4 Load test.gbl with xmodem. 5 Reboot and its working well with the pin PA01 its high, SWD debug its working in main bootloader and in app, force bootloader only working on boot. = all its working very well and the flash its clean from old things.

I have reading it can being problem with uart and SWD but i think its only if using the same port grupe ?!?

Can you making one new app with an older / lower version of the EZSP and the same config ?? Have not looking in the SKD/EZSP change logs if EZSP its not supported on later releases on 256k devices.

Thanks in advance MW

[MattWestb]

From the Zigbee EmberZNet: ver 6.7.6.0 release notes: 6 Removed Items Removed in release 6.7.1.0 SDK no longer contains prebuilt application binaries for EM35x and 256k flash size devices except for the following: • NCP images(ncp-spi, ncp-uart-hw, ncp-uart-sw) for • EM3588 • efr32mg1p133f256gm48 - brd4150c • efr32mg1p232f256gm48 - brd4151a • Sniff image for EM3588 • xncp-commshub-uart-dual for efr32mg1p132f256gm48 – brd4155a Applications may still be generated and built via Studio

I think 6.7.1.x its on the border for the 256k devices. So 6.7.0.x or 6.6.4.0 its more likely to working. Have looking thru the release notes from 6.5.0 GA to 6.7.0.0 and cant finding any issues for EFR32MG1P132F256GM32 that is not fixed only the next 6.8.x.x its the last supported release for 256k chipps.

Is it also possible building a sniffer firmware for the EFR32MG1P132F256GM32 ? It can being a good application for old used bulbs ;-)

[MattWestb]

I think i have finding the NCP app problem. I was longer away, and you was nearly on spott !!! The HW with the external flash and NPC comport its the key.

Info from the EFR32MG1-DataSheet.pdf and efr32xg1-rm.pdf. The MG1 have 2 USART and one is hardware connected to the external flash on the ICC-1 module working in synchronous mode. The big question its witch USART the external flash and the NCP comport using. Both USART0 and USART1 can being configured to pin PC10(USx_TX/MOSI) and PC11(USx_RX/MISO) with alternate location option 15 or PB14(USx_TX/MOSI) and PB15(USx_RX/MISO) with option 9 for NCP com and PD15(USx_RX/MISO) and PD14(USx_TX/MOSI) with option 22 for external flash communication. If external flash and NCP com its mapped with same USART (USART0 and/or USART1) to the port/pins then its 110% problems. Is it possible in Simplicity Studio to verify witch USART(USART0 / USART1) the external flash and the comport for the NCP its linked / coded in the program ? Also if only NCP its configured and the external flash not it can being problem that under the hood the SDK its linking the pins or not to the external flash in the HW and making it impossible using the comport for the NCP or crashing the NCP then strange signals on the PD pins.

Can you pleas looking if you can finding some thing in the SDK that can helping with the USART problem. As a last trye i can desoldering the external flash from one module. Its not so easy but possible and can damage other components in the module and its not recommended for HA comunity beginners.

Thanks in advance !!

MW

[mtx512]

I haven't configured UART1, only UART0 is configured with 2 pins TX(PC10), RX(PC11) so code code is not initialising UART1. In my bootloader the SPI interface is also disabled so won't get initialised. Same in NCP the SPI interface is disabled, the reason being the SPI interface is used for NCP serial coms that replaces the UART interface.

[MattWestb]

Simply Commander Info:

[MattWestb]

Have getting one set with RX and TX pins changed from @jnicolson and @grobasoz. grobasoz have only second bootloader (dangerous for beginners if making full erase if flash) but jnicolson have both in s37 file. jnicolson NCP its behavior like yours (No terminal output and must booting bootloader for SWD). But grobasoz NCP its putting out in Windows with Extra PTTY: ▒▒�~ and in Minicom -H :

Welcome to minicom 2.7.1

OPTIONS: I18n
Compiled on May 3 2018, 15:20:11.
Port /dev/ttyUSB1, 14:13:41

Press CTRL-A Z for help on special keys

11 1a c2 02 8b c2 8a 7e

The first "11" its coming from the reboot of the EFR but i think its looks promising !!

So the next step its trying out Z3GatewayHost.

Do You have some more instructions for that ??

Thanks in advance !

Regards Mattias W