• State TI Thinks Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 399 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AWR1843AOP: System Freezes After SOC_softReset Call in SBL

John Smith
Prodigy 50 points
Part Number: AWR1843AOP

Hi,

I have a board with the AWR1843AOP running the mmWave SDK with the default SBL (plus a few modifications to use the CAN interface).

When I update the firmware in the SBL, the device freezes at some point after calling SOC_softReset and before reaching the main function of the MSS, requiring a power cycle.

I have experimented a bit and can easily recreate the issue by simply calling QSPIFlash_sectorErase and then SOC_softReset (or a warm reset) in the SBL. I tried performing an erase at the same memory location from the application code before resetting and have had no issues.

I found this thread about a very similar issue on the 6843, but it hasn't been much help. I checked the interrupt registers for the QSPI and MCAN cores and both are clear of any pending interrupts. The only thing in the errata for the AWR1843AOP that seems related is MSS#45. However, waiting on QSPI_isBusy doesn't make a difference.

Because this issue is occurring during a reset, I'm having a hard time debugging it.

Is this a known issue, or could you provide some information on how I could further debug this?

  • 0
    TI__Genius 15046 points

    Hi,

    We have seen this issue before (link to thread).

    This happens if the flash is busy performing an operation when reset occurs, the ROM bootloader of the device tries and fails reading firmware from the busy flash chip. The ROM bootloader then defaults to waiting for firmware over SPI by design. Since you mentioned that you can recreate this issue by calling sectorErase in flash, I assume that this is also the case in your application.

    The solution to this is to either ensure that the flash is not busy before doing a soft reset, or to reset the flash before the soft reset occurs. My last response in the thread I linked to contains code to perform flash reset (resetting the SFLASH stops any ongoing operations and puts it in standby mode).

    Regards,

    Aayush