• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 102 subscribers
  • Views 590 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.

AM6548: An issue with using the Uniflash tool on Sitara AM6548-HS SR2.1.

Novica Jovanovic
Intellectual 470 points
Part Number: AM6548
Other Parts Discussed in Thread: UNIFLASH, , AM6526

Hello All,

I have a question regarding the issue we have when we try to use the Uniflash tool on AM6548-HS SR2.1.

My configuration is:
SDK - ti-processor-sdk-rtos-am65xx-evm-07_03_00_09
PDK - pdk_am65xx_07_03_00_54 (processor_sdk_rtos_am65xx_07_03_00_09)
AM6548-HS - programmed with our custom key

We have our custom board based on Sitara AM6526-GP SR2.1. (we have a few boards assembled with AM6548-HS SR2.1.) on which we use QSPI flash as a primary and UART (MCU_UART) as a backup boot device.

We are using the Uniflash tool to write images (SBL, SYSFW and APP) to NOR flash, and we didn't have any problem using this tool on our boards with AM6526-GP SR2.1.

But we detected the problem when we tried to use Uniflash to program NOR flash on board which has AM6548-HS (programmed with our key).

The flashwritter app was built for HS Sitara, and it is signed in a proper way with our key.

But on boards with AM6548-HS (HSSE - programmed with key) the Uniflash tool does not work. The Flashwriter application is loaded to the R5 core, the problem occurs when sysfw header frame is sent then the target responded with 0x18.
The other strange thing on AM6548-HS is while receiving the header sequence, in parallel the R5 is sending character 'C' (0x43), and the problem with that is that this sending is not triggered by the Flashwritter application on R5. (see picture below)




The board with HS and the board with Non-HS silicon are completely the same (the schematic and PCB are the same). Below I will put the output from the ROM bootloader:

Fullscreen AM6548_HS_ROM_output.txt Download 
02000000011a00006d617877656c6c000000000048535345000201000002010002a60000010002002e08e296cf63f9842019afd8b0582240a2874890ef58bff3a1dacb2235519af10ccf494c627c2b66b6341a1c219824cc3d5aa207c7085fb0bc4b36a6df6a58b4fda9c5e29d9c7f08b63f111bd6e572d099e6f76d33e1416ed6e915735c844ad2573780ff54eea9413af5f54f40621230e6a38e4d2503673006eeb9ca7edbba05f2b545eb088dc5930b3d8088acf65196f2c8b9f32ce4a6f882150a434f00000000000000000000000000

-----------------------
SoC ID Header Info:
-----------------------
NumBlocks            : 2
-----------------------
SoC ID Public ROM Info:
-----------------------
SubBlockId           : 1
SubBlockSize         : 26
DeviceName           : maxwell
DeviceType           : HSSE
DMSC ROM Version     : [0, 1, 2, 0]
R5 ROM Version       : [0, 1, 2, 0]
-----------------------
SoC ID Secure ROM Info:
-----------------------
Sec SubBlockId       : 2
Sec SubBlockSize     : 166
Sec Prime            : 0
Sec Key Revision     : 1
Sec Key Count        : 2
Sec TI MPK Hash      : 2e08e296cf63f9842019afd8b0582240a2874890ef58bff3a1dacb2235519af10ccf494c627c2b66b6341a1c219824cc3d5aa207c7085fb0bc4b36a6df6a58b4
Sec Cust MPK Hash    : fda9c5e29d9c7f08b63f111bd6e572d099e6f76d33e1416ed6e915735c844ad2573780ff54eea9413af5f54f40621230e6a38e4d2503673006eeb9ca7edbba05
Sec Unique ID        : f2b545eb088dc5930b3d8088acf65196f2c8b9f32ce4a6f882150a434f000000


We had a similar issue one year ago with the first samples of AM6526 that we received, but when we received another batch of AM6526 samples everything works fine with these samples.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1088333/am6526-an-issue-with-using-the-uniflash-tool-on-sitara-am6526-sr2-1


Do you need some additional information? So you can check internally on your side, maybe we received the samples of HS Sitara which have similar issues as we have one year ago with the first samples of AM6526-GP.
If that is the case, can we solve this issue with some patch for the flashwritter app?

Best regards,
Novica

  • 0
    TI__Guru* 84515 points

    Hello Novica

    I will assign to Hong to see if he has any pointers. As previously discussed our ability to support HS development on AM65 is limited. I do not think the uniflash utilities have been tested with HSFS silicon etc. 

  • 0 in reply to Mukul Bhatnagar
    Intellectual 705 points

    Hello Mukul and Hong, one more thing to mention:

    The strange this is: if we upload via Uniflash/UART not the flashwriter application but the SBL (build for UART), then everything works fine:

    • the SysFW is loaded correctly via Uniflash/UART
    • the SBL loads our application correctly via Uniflash/UART (which takes a very long time)

    This all is the case using our own R&D key pair against a custom board programmed with our R&D key.

    I do not understand why loading the combination flashwriter+SysFW fails, but the combination SBL+SysFW works

    Regards, Ruediger

  • 0 in reply to Ruediger Wurth
    TI__Guru* 84515 points

    Hello Ruediger

    From internal records and discussions it does not appear that Uniflash for tried and tested with HSFS. So this maybe an area that we have not supported. 

    I am still investigating if there are any generic pointers we can send your way. Hong is not the right expert on this. 

    Regards
    Mukul 

  • 0 in reply to Ruediger Wurth
    TI__Intellectual 1160 points

    Hello Ruediger,

    Can you please try below

    - Keep the board in UART boot

    - Connect MCU UART port of the board to a serial console app (I am using teraterm as reference here)

    - Confirm that character 'C is getting printed on the console

    - Download the Uniflash ti app image (.tiimage) through XMODEM (Teraterm menu 'File->Transfer->XMODEM->Send..'

    - Check if flash programmer download completes successfully and if the character 'C' keeps getting displayed after flash programmer download

    - Please share the full console log here

    - Pratap.

  • 0 in reply to M V Pratap Reddy
    Intellectual 705 points

    Hello Pratap,

    I did the test with my custom board programed with my R&D key. Using the flashwriter application signed with that R&D key.

    The result is that download of flashwriter app via xmodem is successful, but after download, the target answers with double 'CC' characters.
    This seems strang to us.

    Output as text (in order that you can analyze with parse_uart_boot_socid.py):

    02000000011a00006d617877656c6c000000000048535345000201000002010002a60000010002002e08e296cf63f9842019afd8b0582240a2874890ef58bff3a1dacb2235519af10ccf494c627c2b66b6341a1c219824cc3d5aa207c7085fb0bc4b36a6df6a58b4fda9c5e29d9c7f08b63f111bd6e572d099e6f76d33e1416ed6e915735c844ad2573780ff54eea9413af5f54f40621230e6a38e4d2503673006eeb9ca7edbba0588c5f2d96b9655cb916845b7f02dd9a7796a244e544d8b4b0bd2073797CCCCCCCCCCCCCC

    But I guess writing such information forth and back will result in slow progress, since we already analyzed much more than that (e.g. see post previous conversation).
    We would favorite to have a call.

    Rest regards,
    Ruediger and Novica

  • 0 in reply to Ruediger Wurth
    TI__Guru 71260 points

    Hello Ruediger,
    Thanks for your reply.
    Let's see Pratap's feedback for next steps...
    Best,
    -Hong

  • 0 in reply to Hong Guan64
    Intellectual 705 points

    Hello Pratap,

    if a call is not possible, what should be the next step to be done to analyze the issue?

    For testing purposes Novica configured the WKUP_UART at the beginning in main() of the flashwriter application to check if main() is started, but there was no output at all visible. So it looks like the ROM bootloader is stumbling somehow.

    Regards,
    Ruediger