CYW43907 stuck in ROM bootloader

[krystofslavik]

Hi,

I am working on a CYW43907 custom board that is battery powered. Very rarely I experience an issue that the CYW43907 gets stuck and cannot be reset using the reset pin (REG_ON signal). The only way to recover from this state is to cut the power which means to physically disconnect the battery.

After doing sniff of the communication between the MCU and the SFLASH on the quad SPI bus I discovered that the MCU reads a few bytes from the SFLASH (at addresses 0x00, 0x0C, 0x00, 0x0C, 0x10, 0x18, 0x14 in this order) and then stops. After pulling the reset line it does the same again. The data that is read from the SFLASH is correct and the signal looks OK on an oscilloscope.

When the issue occurs I tried starting a debugging session in the WICED IDE. The MCU stays in the reset handler and does not execute any instructions. However, it is possible to read registers and memory which means that the JTAG interface is working.

My guess is that the MCU gets stuck in the ROM (first stage) bootloader which is supposed to load the application (second stage) bootloader from the SFLASH. Is there any reason for the ROM bootloader to stop before loading the firmware from the SFLASH? Is there anything else that can be tested or measured in order to find the cause of the problem?

Thanks, Krystof

[Qi_Colin]

Hi @krystofslavik :

Did you do any cross test with another board? Does it have the same issue?

I think it maybe caused by the compatibility of MCU and flash.

If possible, please cross test the flash MX25L6433FZNI-08G which is applied on CYW943907AEVAL1F EVK.

Best Regards,

Colin

[krystofslavik]

Hi @Qi_Colin ,

we are using the MX25L6433FZNI-08G flash. Also, I can see from the sniff that the SPI communication is fine.

We have manufactured 100 boards and so far the issue has appeared multiple times on several boards. A board boots up hundreds of times and works perfectly fine, then the issue appears and the board will not boot up no matter how many times it is reset. The only way to fix it is to disconnect the power. Then it works again many times until the issue appears again. Seems like there is some internal state of the MCU that is not reset when the REG_ON signal is pulled down.

Thanks, Krystof

[Qi_Colin]

Hi @krystofslavik :

What's the frequency of QSPI sflash is working on?

Could you help to check the value of "PLATFORM_CHIPCOMMON->clock_control.divider.bits.serial_flash_divider" in your firmware?

Default value of this parameter is "NORMAL_READ_DIVIDER (6)", means clock of QSPI is 26.67MHz.

If it is a high frequency, it maybe causes QSPI work unstable.

Please help to check it.

Best Regards,

Colin

[krystofslavik]

Hi @Qi_Colin ,

the issue happens before the firmware is loaded so as far as I can tell the divider set in the source code can't have any effect on this. Using oscilloscope I have measured 3.73 MHz on the SPI CLK line.

But to answer your question anyway, the value of PLATFORM_CHIPCOMMON->clock_control.divider.bits.serial_flash_divider is 6 right after boot. I have kept this value at its default set by the SDK.

Thanks, Krystof

[Qi_Colin]

Hi @krystofslavik :

If so, please help to do some cross test, if possible, exchange the flash of FA board and normal board.

Because this issue happened before the firmware loaded, I think you should do more test of HW, like the power status when power on, QSPI signals and so on. 

ROM code normally read flash, and halt with wrong data, therefore we should find out the difference between abnormal board and normal board.

Best Regards,

Colin

[krystofslavik]

Hi @Qi_Colin ,

thanks for the suggestions. I will do some additional HW tests and get back to you once I have more information. However, it may take a while since the issue is hard to reproduce.

Best regards, Krystof

[krystofslavik]

Hi @Qi_Colin,

I have done more measurements and created a few screenshots so that you have a better understanding of what is happening.

In the first image there is a sniff of the SPI communication captured using a logic analyzer. This was recorded when there was no issue. The internal bootloader reads a TRX header, then the communication pauses for 12 ms and after that the main bootloader (waf.ota2_bootloader) is read from the flash. When there is the issue then the communication stops just after the TRX header is read as indicated by the red line.

This is a zoom in on the first part where the TRX header is read. This part of the communication looks exactly the same whether the issue is there or not. This means that the communication with the flash works.

I have also checked the quality of the signal using an oscilloscope. Purple is CLK and blue is MISO. I would say the signal looks good. The quality of the signal is the same on multiple boards regardless of whether the issue appears or not.

I have also checked all power rails and haven't found anything suspicious. Also please note that once the issue appears the board can stay in this state for days while I can keep resetting the MCU hundreds of times and it still won't boot. But as soon as I reset the power it boots immediately. This leads me to believe that this is not a signal quality or flash compatibility issue. Yes, the issue is caused by a random phenomenon but then it gets the MCU to a state from which it can't correctly reset.

Could you please describe what is happening in the ROM bootloader during the 12 milliseconds after it reads the TRX header and before it starts reading the main bootloader from the SFLASH? Maybe there is some reason for the ROM bootloader to halt that is not related to the SFLASH?

[Qi_Colin · Accepted solution]

Hi @krystofslavik :

Sorry for that I'm not sure what happened during the 12ms.

Generally, power is the mainly reason caused failure when MCU booting.

Therefore, please help to double check the schematic with the reference design and the power rails, especially the core voltage and  VBat circuit.

OTOH, I also suggest you contact with our local Infineon Sales or Infineon distributors for help as well because it's more helpful if we can get the failure samples.

Best Regards,

Colin