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

AM2434: AM2434 QSPI ROM boot troubleshooting

Toby Grabham
Prodigy 110 points

Part Number: AM2434
Other Parts Discussed in Thread: UNIFLASH

I'm trying to get our custom board to boot from QSPI flash.

We use the same flash device, and copied the schematic from the AM243x launchpad.

I have modified the SBL DFU uniflash project for our board.
I have modified the null bootloader project for our board.

USB DFU mode is set as the fallback boot method with resistors.

I run the usb_dfu_uniflash.py script with our config file to write the null SBL @ 0x0 and 0x400000.

The modified SBL DFU uniflash runs OK -- I see the USB device name change from "AM64x DFU" from the ROM boot to "AM64x-AM243x DFU" set in the SBL.

However, after programming the null SBL, when I change the bootswitches to QSPI flash, the device doesn't boot and falls back to USB DFU mode instantly.

I can load programs via JTAG and can successfully read the qspi flash -- I have read back and checksummed each 32KiB block of the bootloader and it matches the null bootloader .tiimage on my PC prior to upload.

I have tried putting a loop_forever as the first line in main() on the null bootloader, but when I connect to r5_0_0 it's never at a valid execution point.
I think the fact the "AM64x DFU" device instantly appears also indicates it's failing at the ROM boot stage and falling back to the secondary boot method.

We have tried putting a 100k pull down on the DQS->LBCLKO pins -- that net was floating around 0.7V prior to this before any traffic started and is now close to 0V before traffic so this looks like a worthwhile mod.

I have tried with B8 in positions 0 and 1 -- from the AM243x TRM 0 seems to be correct for the DQS->LBCLKO connection, although the MCU-PLUS-SDK tells you to set this to 1 on the launchpad. 

I am using mcu_plus_sdk_am243x_10_01_00_32.

Questions:

Are there any logs/status info from the ROM bootloader that I could check for clues?

Do you have any further suggestions?

  • 0
    TI__Mastermind 21935 points

    Hi,

    Toby Grabham said:
    The modified SBL DFU uniflash runs OK

    Can you share the flashing logs.

    Toby Grabham said:
    I can load programs via JTAG and can successfully read the qspi flash -- I have read back and checksummed each 32KiB block of the bootloader and it matches the null bootloader .tiimage on my PC prior to upload.

    Does this mean you flashed the programs via JTAG? I just want to check if this is the DFU UNIFLASH issue or something else, so if you can flash using JTAG then please check if you are able to boot from QSPI after that.

    Best Regards.

    Meet.

  • 0 in reply to Meet Thakar
    Prodigy 110 points

    > Can you share the flashing logs.

    I assume you mean from the usb_dfu_uniflash.py script? See below

    Parsing config file ... Parsing config file ...... - Pastes.io

    > Does this mean you flashed the programs via JTAG? 

    I meant I was loading programs into RAM via JTAG and running them OK. 

    > so if you can flash using JTAG then please check if you are able to boot from QSPI after that.

    ================== JTAG Uniflash Menu =========... - Pastes.io

    Flashed with JTAG uniflash OK but still have the same symptoms.

  • 0 in reply to Meet Thakar
    Prodigy 110 points

    Do you have any further suggestions please?

  • 0 in reply to Toby Grabham
    TI__Mastermind 21935 points

    Hi Toby,

    I will check internally if there is any additional configuration needed while booting from QSPI, meanwhile could you let me know what address you see once you connect to r5f0_0 in CCS:

    Toby Grabham said:
    but when I connect to r5_0_0 it's never at a valid execution point

    Best Regards,

    Meet.

  • 0 in reply to Meet Thakar
    Prodigy 110 points

    If I connect to R5_0_0 after an unsuccessful QSPI boot, the R5 is normally somewhere in the 0x4182xxxx range (e.g. 0x4182752C, 0x418274DA, 0x41827504), although I did manage to pause it on 0x08. When I'm pausing it here, I can see the AM64x DFU device in device manager so assume it's in the USB DFU portion of the ROM.

  • 0 in reply to Toby Grabham
    TI__Mastermind 21935 points
    Toby Grabham said:
    I can see the AM64x DFU device in device manager so assume it's in the USB DFU portion of the ROM.

    Yes, It is stuck in ROM Code.

    Could you check if you can boot the same image (sbl_null) via DFU boot or not? 

  • 0 in reply to Meet Thakar
    Prodigy 110 points

    Sorry for slow update, I have been looking at other parts of the project as we did make some progress on this.

    All the boards I've tried will boot the SBL from the QSPI flash with the ROM boot switches set to xSPI boot in 1-1-1 mode (50Mhz), and the switches set to regular SPI mode (6.25Mhz).

    The very first board I tried now will also boot the SBL in QSPI 1-1-4 mode. It is the only board that works in this mode so far.

    With the boards that do not boot in QSPI 1-1-4 mode, the flash chip just does not respond to the first command in 1-1-4 mode.

    Once the boards have booted our user application flash access in 4d-4d-4d mode is absolutely fine.

    We are continuing to investigate.

  • +1
    Prodigy 110 points

    This has been resolved now.

    In the S25HS512T flash, configuration register 1, bit 1 sets the data width to 4 bits wide in 1-1-4 mode, and is turned OFF by default in the non-volatile register.

    Interestingly we eventually found 1 of prototype boards did boot, and this bit was turned ON in the flash -- which is not the normal default! This nudged us in the right direction.

    Thanks for your comments.