• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 569 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.

Original question:

AM2634-Q1: Will the RBL reset the external QSPI Flash before booting up SBL/APP?

AM2634-Q1: RBL will stall if warm-reset happened at the same time of erasing external Flash

Will Gao
Intellectual 2335 points
Part Number: AM2634-Q1

Hi BU, 

In the early thread, I submitted a question about the RBL's behavior after the warm-reset happened at the same time of erasing external Flash. And Aakash proposed that we can reset the Flash via board hardware design, i.e. route the RST pin of Flash device to warm-reset signal of AM263x, so that we can avoid the situation. 

However it is hard to achieve this if the RESET pin for Flash chip is hided by package, for example the following Flash chip: 

I replicated the situation with a project and in LaunchPad, the project is attached here: qspi_flash_dma_transfer_am263x-lp_r5fss0-0_nortos_ti-arm-clang.zip

From the serial terminal, you can see that the device now will not boot again: 

Please give your further suggestions about this issue. 

Regards, 

Will 

  • 0
    TI__Mastermind 26145 points

    Hi ,

    For the given part, I think you should connect the warm reset pin (reset pin) of AM243x to Vcc. But I have assigned the ticket to the expert. I hope he provides a better solution.

    Best Regards,
    Aakash

  • +1 in reply to Aakash Kedia
    TI__Expert 7690 points

    Hi Will, 

    the WSON package for the flash used in both LP and CC platforms of AM263x do not have the reset pin needed to avoid this problem, in this case, the flash reset is tied high internally like the datasheet mentions. Like Aakash suggested before, you would want to tie the reset of the flash to the reset signal of the SoC so that the resets are synchronized and the flash is not left in a partially/incorrectly configured state.

    What is most likely happening is that the flash is getting caught in a busy state due to SoC keeping the Flash active (CSN LOW) with no data being sent while it's issuing a reset; in this state, the controller releases the QSPI lines but the flash remains on and active while this happens. According to the flash datasheet this is a spec violation, and it would explain why the only way of getting it back to operate is by power cycling the flash device.

    Without a reset pin, I don't believe there are any workarounds to this issue other than power cycling the flash device to make it reach standby mode again. Typically, interrupting the flash memory mid-operation without proper use of the HOLD or RESET functionalities can result in errors like the flash getting stuck.

    Best,

    Daniel

  • 0 in reply to Daniel Bermudez
    TI__Intellectual 2335 points

    Hi Daniel, 

    Thanks for your input. Could I use warm-reset signal as a gate for controlling the power supply of Flash device to solve this problem? 

    Hi Aakash, 

    Do you think this problem should be reported to RBL experts? I know it is hard to change the ROM codes version now, but in the future AM26x devices design, I think this point should be considered. 

    Regards, 

    Will 

  • +1 in reply to Will Gao
    TI__Mastermind 26145 points

    Hi ,

    The feasibility of what is requested is very low. The flash on the board can be configured in any mode supported with separate read cmd and delays etc. and the controller is configured accordingly to work with the same before the reset.

    But when you warm reset - the flash controller in SoC resets and default settings will be in place work for standard read i.e. 0 dummy cycles, read id as 0x3 and so on. RBL will configure the controller to work at mode supported by BOOTMODE. But will fail to configure the flash on the board for the same as the flash is still configured at other protocol which RBL cannot determine. Hence due to failed negotiation of protocol, the RBL won't be able to boot the device in a stable stage.

    Hence, it is required to reset the flash when the SoC is reset because this will reset the flash as well as the controller to default 1-1-1 mode. In future, maybe if TI provides a SIP package with integrated flash for AM26x devices, this problem will be taken care of.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    TI__Intellectual 2335 points

    Hi Aakash, 

    Well understood. SIP will be the ultimate solution for those kinds of Flash-boot issues...Waiting for the SIP devices to be released...

    Regards, 

    Will  

  • 0 in reply to Aakash Kedia
    TI__Intellectual 2335 points

    Hi Aakash and Daniel, 

    Could BU prepare a simple slides to illustrate the hardware design for avoiding this issue? Thanks a lot. 

    Regards, 

    Will 

  • 0 in reply to Will Gao
    TI__Expert 7690 points

    Hi Will,

    I am not sure there are any workarounds for this problem if the reset pin from the flash is inaccessible. I will discuss options with the team and get back to you on this offline 

    Best,

    Daniel