• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 798 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.

Jacinto2 RBL info.

Rajesh Joshi
Prodigy 30 points

Hello All,

We have 2 return hardware units from customer  in that ARM is continuously reloading, ARM boot not successful. We are using Jacinto2 (J2 IC) in  our project and memory details listed below.

 

1)      External Serial Flash 4MB (ARM + DSP + UBL( user boot loader))

2)      SDRAM 16MB

 

As per the TRM the RBL loads the UBL( the UBL code was written by delphi) code from serial flash to SDRAM and gives control to UBL, then UBL loads the ARM application code from serial flash to SDRAM and if there is checksum mismatch then UBL fails. The DSP application code loaded by ARM form serial flash to SDRAM.

 

Now my question is when UBL fails to load ARM application code from Serial flash to SDRAM (maybe due xsum mismatch) RBL re-triggers UBL once again ?

Because we don’t have any retry mechanism in UBL code, I think RBL is having retry mechanism right?

 

If ARM SOFT_RESET is issued then UBL  will be reloaded from serial flash to SDRAM ?

  • 0
    TI__Mastermind 25170 points
    Hi Rajesh,
    I don't have much knowledge on Jacinto 2, but generally in most devices, RBL it tryes to download an image to RAM (typically to internal RAM, but I don't know if J2 has one), checks image check sum, and eventually jumps to the image (UBL) start address.
    That is, once you see UBL running, it means RBL is no longer running as it considers it's job as done.
    If you experience device restarts, then it must be some type of reset , most probably one of these:
    - UBL requests global software reset (but you say it doesn't)
    - watchdog has been overflown, due to not disabled or not serviced by RBL

    If RBL fails to load valid UBL, RBL can try other interface (SDCARD, UART, etc) , or retry in a loop forever (with the help of watchdog or not). I'm not sure how it is done in J2. Should check J2 DM/TRM for details.
  • 0 in reply to Stanislav Stilyanov
    TI__Mastermind 25170 points
    Forget to say, that due to the above, it is UBL code's responsibility to handle any failures during its job. Alternatively, it can setup a watchdog accordingly and wait for restart in case of malfunction.
  • 0 in reply to Stanislav Stilyanov
    Prodigy 30 points
    Hello Stanislav,

    Thanks For sharing very good information.

    can plz forward my query's to relevant team who know J2 very well...!

    i had gone through the TRM/DM , but i don't have clear information on RBL.
    1) what happens if UBL fails to load ARM application code from serial flash to SDRAM, bcz in UBL source code we don't have ARM application re-loading mechanism.
    2) The UBL uses SPI communication to load ARM appl'n from serial flash into SDRAM
    3) we have connected Digital oscilloscope, in ARM appl'n reloading continuously
    4) Out of many HW's only 2/3 got rejected in customer place bcz of reloading problem.
    5) Is there any chances of Serial flash problem, or SPI any communication problem?
    6) I've reloading images captured in digital oscilloscope. How to attach images?
  • 0 in reply to Rajesh Joshi
    TI__Mastermind 25170 points
    Rajesh,
    1) UBL is the only running software at that time. It's up to UBL what happens upon failed loading attempt.
    5) Sure, flash memories can fail as any other component. Please refer to the flash datasheet to verify if it has error correction mechanism. Even then, something can go wrong. For example, too much bits got inverted to be possible to detect or correct.
    SPI communication problem of course can happen, but if all bad boards fail the same way, it's seems less plausible (at least to me).
    6) Thanks for the scope images. What I can see on them, is that there is no device restarts. Just retrials to reload application image. That is, there is no ROM Bootloader involvement as it kicks in only after resets. See 1) again.

    At last, it is not impossible to have the UBL itself corrupted especially if it is not CRC (or other ) protected.

    Some questions: what is the J2 device part number you are using? Flash memory part number? Do yo u have access to the UBL source code?

    Regards,
    Stan