• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 265 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.

TMDS64GPEVM: Strange behaviour of AM64 GPEVM after "successful" flash of SOC initialization binary

Alexander Baitinger
Prodigy 20 points

Part Number: TMDS64GPEVM

Hi support,

my AM64 GPEVM board behaves very strange after i flashed the SOC initialization binary to it as refered in your MCU+ SDK 08.03. getting started TI "Flash SOC Initialization Binary" section.

As a short background info, i already setup another board some time ago and everything worked as described. With this previous board i flashed the SOC init binary successfully, debugging in CCStudio worked, Linux booted etc.

Now i have a new board, which had no SOC init binary flash and i already worked with a Linux sd card (custom Linux distribution) in it. After some time i wanted to debug my R5F application with CCStudio, which did not work correctly. As far as i understand, for this to work, the SOC initialization binary needs to be flashed to be able to run applications from CCStudio. Then i rembered the topic of SOC init binary flashing in the getting started and tried it again. Now a description of the behaviour:

  •  Already at step "You should see character "C" getting printed on the UART terminal every 2-3 seconds as shown below" i noticed that i had to wait nearly 2 min. for the output to pop up, which i don't remember to be so long for the 1st board which i setup, but i just moved on with the next steps
  • I ran the command "python uart_uniflash.py -p COM<x> --cfg=sbl_prebuilt/am64x-evm/default_sbl_null.cfg" and the output was "successful" as described in the getting started, everything seemed to work
  • I followed the next steps and afterwards powered on the board again
  • The output was not as expected from the getting started, which i remembered from the 1st board, but instead was (waited 1-2 min. for this to pop up):
  • I thought: "okay i will just repeat the steps from the beginning and start over again"
  • Again i changed to UART BOOTMODE, powered on the EVM and looked at the output, which again needed some time before it displayed:
    • The mentioned "C" in your getting started, which gets printed every 2-3 seconds, became a "Á". Everything else was not readable anymore.
  • I thought it's maybe just a display error and tried to move on until the uart_uniflash step.
  • Ran the command and this was the output:
    • The board sends a completely different response as expedted and like in the other outputs as well
  • After that i tried to start Linux via SD card in the usual BOOTMODE but it's not starting anymore.
  • It doesn't matter how often i restart, it seems like it is in a "undefined" behaviour.

I also tried the section "SOC Initialization Using SD BOOT" in the getting started but this does not solve the problem. It still prints the "Á" instead of "C" and nothing is readable, Linux still does not boot.

Do you know how to resolve this behaviour? Is it possible to re-init/reset the board somehow? Is it possible that the custom Linux distribution i sued (not the one from TI) might effect the system permanently in some way which i ran before i tried to flash the SOC init binary? Before i tried the SOC init binary flash the custom Linux version worked fine and i was able to interact with the system via COM Terminal or SSH and start my R5F and Linux application.

Thanks in advance for your help!

BR

Alex

  • 0
    TI__Genius 12330 points

    Dear Alex,

    thanks for the query, i have few questions

    1. can you describe 

    Alexander Baitinger said:
    custom Linux

    please allow us to recreate the issue and get back with an answer.

    Regards

    Anshu

  • 0 in reply to Anshu Choudhary
    Prodigy 20 points

    Hi Anshu,

    thanks for your reply. Unfortunately it's not that easy to get some informations about the Linux distribution right now and would take some time.

    Therefore a more general question, is it possible to reset the board somehow, e.g. the bootloader?

    Does the uart flash script even influence the SD boot mode, which also is not working anymore? Looks like the bootloader is not working.

    BR

  • 0
    TI__Mastermind 46656 points
    Alexander Baitinger said:
    I ran the command "python uart_uniflash.py -p COM<x> --cfg=sbl_prebuilt/am64x-evm/default_sbl_null.cfg" and the output was "successful" as described in the getting started, everything seemed to work

    Hello Alex,


    May I know why you are using default_sbl_null.cfg file and what UART settings you used to see the content in UART console?

    Usually when you set baud rate values ​​wrong and you can get this kind of problem and make sure you configure baud rate as 115200.

    You should use the default ospi cfg file to load the binaries into external memory.

    Alexander Baitinger said:
    Do you know how to resolve this behaviour? Is it possible to re-init/reset the board somehow? Is it possible that the custom Linux distribution i sued (not the one from TI) might effect the system permanently in some way which i ran before i tried to flash the SOC init binary

    Even if your HW is not working properly, you can follow below procedure to initialize SOC and remove SD card from your HW and try below steps.

    1. Power OFF and Kept Hw in to NO boot mode


    2. Try using below command to load binaries in external memory

    C:/ti/mcu_plus_sdk_am64x_08_02_00_31/tools/boot python uart_uniflash.py -p COM8 --cfg=sbl_prebuilt/am64x-evm/default_sbl_ospi.cfg

    COM and folder path should be updated according to your input's .


    3. Power OFF and Kept Hw in to OSPI boot mode

    4. Power ON

    Please let me know if you are still facing any problem.

    Regards,

    S.Anil.