Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flash successful but probe fails #70

Open
Emanuele-Spatola opened this issue Jun 5, 2024 · 7 comments
Open

Flash successful but probe fails #70

Emanuele-Spatola opened this issue Jun 5, 2024 · 7 comments

Comments

@Emanuele-Spatola
Copy link

I'm trying to flash a Silab MGM210PA32JIA2 module (same used in the Yellow) connected to a raspberry pi 4.
the module is connected to the pi this way:

GPIO 8: TX
GPIO 9: RX
GPIO 10: CTS
GPIO 11: RTS
GPIO 24: !BOOT
GPIO 25: !RESET

I enabled the uart4 with the cts/rts, and the pins configuration looks good:

$ raspi-gpio get 08-11
GPIO 8: level=1 alt=4 func=TXD4 pull=NONE
GPIO 9: level=1 alt=4 func=RXD4 pull=UP
GPIO 10: level=1 alt=4 func=CTS4 pull=UP
GPIO 11: level=0 alt=4 func=RTS4 pull=NONE

The flashing seems to be working correctly (note that I connected the !BOOT pin to the same GPIO used in yellow, so I can use the --bootloader-reset yellow):

$ universal-silabs-flasher --device /dev/ttyAMA4 --bootloader-reset yellow flash --allow-cross-flashing --firmware NabuCasa_Yellow_EZSP_v6.10.3.0_PA32_ncp-uart-hw_115200.gbl
INFO Triggering yellow bootloader
INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
INFO Launched application from bootloader
INFO Detected bootloader version '1.9.0'
INFO Probing ApplicationType.CPC at 460800 baud
INFO Probing ApplicationType.CPC at 115200 baud
INFO Probing ApplicationType.CPC at 230400 baud
INFO Probing ApplicationType.EZSP at 115200 baud
INFO Probing ApplicationType.SPINEL at 460800 baud
INFO Triggering yellow bootloader
WARNING Bootloader did not launch a valid application
INFO Detected ApplicationType.GECKO_BOOTLOADER, version '1.9.0' at 115200 baudrate (bootloader baudrate 115200)
NabuCasa_Yellow_EZSP_v6.10.3.0_PA32_ncp-uart-hw_115200.gbl [####################################] 100%

Using the --verboseoption I can see the bootloader sends "upload completed succesfully", then the flasher sends "2" that corresponds to "run application" but from that moment on the serial goes silent:

$ universal-silabs-flasher --device /dev/ttyAMA4 probe
INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
INFO Probing ApplicationType.CPC at 460800 baud
INFO Probing ApplicationType.CPC at 115200 baud
INFO Probing ApplicationType.CPC at 230400 baud
INFO Probing ApplicationType.EZSP at 115200 baud
INFO Probing ApplicationType.SPINEL at 460800 baud
Error: Failed to probe running application type

If I connect to the serial and set the !BOOT pin to low I see the bootloader prompt:

Gecko Bootloader v1.9.0
1. upload gbl
2. run
3. ebl info
BL > 

Sending 2 or 3 will make the menu be printed again.
Looking up the bootloader documentation option 3 does nothing, option 2 reprints the menu if no application is found or if the last application upload was unsuccessful.

I notice from other people logs that the module shipped with the Yellow have the bootloader version 2.0.1. Can that be the issue?
Do I need to update the bootloader?
In this case how do I do it? Do I need to use the Simplicity Commander?

@puddly
Copy link
Collaborator

puddly commented Jun 5, 2024

You can find all of the firmware images (including the bootloader) here: https://github.com/NabuCasa/silabs-firmware-builder/releases/tag/v4.4.2. You can flash the GBL with the flasher.

Can you try flashing OpenThread firmware instead of EmberZNet (also available in the firmware releases link above)? What about the more recent build of EmberZNet?

@Emanuele-Spatola
Copy link
Author

Emanuele-Spatola commented Jun 5, 2024

Thanks @puddly, I flashed the latest bootloader and then tried both latest OpenThread and EmberZNet, but no luck.
Is the probe checking for OpenThread? Is it ApplicationType.CPC?
Is the flasher using hardware flow control? I was wondering if that could be the issue as my understanding was the flasher is not using it, while the application is.

$ universal-silabs-flasher --device /dev/ttyAMA4 --bootloader-reset yellow flash --allow-cross-flashing --firmware yellow_ncp-uart-hw_7.4.2.0.gbl 
2024-06-05 18:13:06.435 bitvego-hub universal_silabs_flasher.flash INFO Extracted GBL metadata: NabuCasaMetadata(metadata_version=1, sdk_version='4.4.2', ezsp_version='7.4.2.0', ot_rcp_version=None, cpc_version=None, fw_type=<FirmwareImageType.NCP_UART_HW: 'ncp-uart-hw'>, baudrate=115200)
INFO Triggering yellow bootloader
INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
WARNING No application can be launched
INFO Detected bootloader version '2.4.2'
INFO Detected ApplicationType.GECKO_BOOTLOADER, version '2.4.2' at 115200 baudrate (bootloader baudrate 115200)
yellow_ncp-uart-hw_7.4.2.0.gbl  [####################################]  100%  
       
$ universal-silabs-flasher --device /dev/ttyAMA4 probe
INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
INFO Probing ApplicationType.CPC at 460800 baud
INFO Probing ApplicationType.CPC at 115200 baud
INFO Probing ApplicationType.CPC at 230400 baud
INFO Probing ApplicationType.EZSP at 115200 baud
INFO Probing ApplicationType.SPINEL at 460800 baud
Error: Failed to probe running application type
$ universal-silabs-flasher --device /dev/ttyAMA4 --bootloader-reset yellow flash --allow-cross-flashing --firmware yellow_rcp-uart-802154.gbl 
2024-06-05 18:26:15.951 bitvego-hub universal_silabs_flasher.flash INFO Extracted GBL metadata: NabuCasaMetadata(metadata_version=1, sdk_version='4.4.2', ezsp_version='7.4.2.0', ot_rcp_version='SL-OPENTHREAD/2.4.0.0_GitHub-7074a43e4' (2.4.0.0), cpc_version='4.4.2-35024512' (4.4.2.35024512), fw_type=<FirmwareImageType.RCP_UART_802154: 'rcp-uart-802154'>, baudrate=460800)
INFO Triggering yellow bootloader
INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
INFO Launched application from bootloader
INFO Detected bootloader version '2.4.2'
INFO Probing ApplicationType.CPC at 460800 baud
INFO Probing ApplicationType.CPC at 115200 baud
INFO Probing ApplicationType.CPC at 230400 baud
INFO Probing ApplicationType.EZSP at 115200 baud
INFO Probing ApplicationType.SPINEL at 460800 baud
INFO Triggering yellow bootloader
WARNING Bootloader did not launch a valid application
INFO Detected ApplicationType.GECKO_BOOTLOADER, version '2.4.2' at 115200 baudrate (bootloader baudrate 115200)
2024-06-05 18:26:39.950 bitvego-hub universal_silabs_flasher.flash INFO Firmware baudrate 115200 differs from expected baudrate 460800
yellow_rcp-uart-802154.gbl  [####################################]  100%          
$ universal-silabs-flasher --device /dev/ttyAMA4 probe
INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
INFO Probing ApplicationType.CPC at 460800 baud
INFO Probing ApplicationType.CPC at 115200 baud
INFO Probing ApplicationType.CPC at 230400 baud
INFO Probing ApplicationType.EZSP at 115200 baud
INFO Probing ApplicationType.SPINEL at 460800 baud
Error: Failed to probe running application type

@puddly
Copy link
Collaborator

puddly commented Jun 5, 2024

Is the flasher using hardware flow control? I was wondering if that could be the issue as my understanding was the flasher is not using it, while the application is.

It's not using hardware flow control but this isn't an issue, all of the firmwares with hardware flow control work just fine without it. This exact tool is used to flash the Yellow.

You can communicate with the bootloader and flash new firmware successfully so your issue may be with NVRAM. Have you tried fully erasing the chip with SWD and re-flashing a known working application with Simplicity Studio?

@Emanuele-Spatola
Copy link
Author

It's not using hardware flow control but this isn't an issue, all of the firmwares with hardware flow control work just fine without it. This exact tool is used to flash the Yellow.

I think Yellow uses hardware flow control as from the schematics CTS/RTS pins are connected to the pi.

You can communicate with the bootloader and flash new firmware successfully so your issue may be with NVRAM. Have you tried fully erasing the chip with SWD and re-flashing a known working application with Simplicity Studio?

Nope. I don't have any specific hardware, can I just connect the SWD pin to the pi?
I tried to install Simplicity Studio and I think it loses it's "simplicity" when you are not using the Simplicity Link Debugger..
Can I do it just with the pi? Are there any links I can have a look at?

I find it strange the that when I send "2" aka "run" to the bootloader it reprints immediately the menu, so it has detected there is an issue but it doesn't print any detail...

@puddly
Copy link
Collaborator

puddly commented Jun 5, 2024

I think Yellow uses hardware flow control as from the schematics CTS/RTS pins are connected to the pi.

The Yellow does for normal communication but it's not required, nor is it used when flashing.

can I just connect the SWD pin to the pi?

You can use a patchset on top of OpenOCD for this: home-assistant/addons#3422

What device is bitvego-hub?

@Emanuele-Spatola
Copy link
Author

You can use a patchset on top of OpenOCD for this: home-assistant/addons#3422

Is there any things I could try out before going down that route? Is there a simpler way to reset the NVRAM?

What device is bitvego-hub?

It's the pi 4. I made a custom hat for my use case (I run home assistant in my van).

20240605_214354

@Emanuele-Spatola
Copy link
Author

Emanuele-Spatola commented Jun 6, 2024

Also wondering if the RTSL could be the issue:

The Secure Boot with RTSL authenticates a chain of trusted firmware that begins from an immutable memory (ROM).
It prevents malware injection, prevents rollback, ensures that only authentic firmware is executed, and protects Over The Air updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants