• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 226 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM2432: SBL_OSPY: PHY mode with flash ISSI works only at 133 MHz for bootloader authentication phase

Andrea Tessadri
Intellectual 567 points
Part Number: AM2432

Tool/software:

Hi support team,

   we have a product based on AM2432 with AM243x SDK and Industrial COMMS 09.02.00.09.

Our flash device is Cypress Semiconductor  S28HS512TGABHM01 certified at 200 MHz and 105° C.

We noticed that the SBL OSPI works only at 133 MHz with PHY enabled and DMA.

If we set the OSPI controller to work at 166 MHz with PHY enabled and DMA, the bootloader authentication will fail and the application image won't be loaded.

We have added some debug functions to check if the image header is read correctly and actually it is (in both cases 133 MHz and 166 MHz):

image header data 0x30 0x82 0x06 0x53

When it comes to Bootloader_socAuthImage it will fail if we set OSPI to 166 MHz with PHY.

This failure seams to be random: some device samples are not affected by this problem, some others fail only at the second power-up (a cold start is sometimes successfull).

We tried to disable the PHY and we discover that the SBL_OSPI stops unespectedly.

If we roll back to a previous version of the AM243x SDK, 08.05.00.24 we have a different behavior:

- the bootloader at 166 MHz with PHY and DMA works well up to 86° C then it fails to read the image header (debug messages report reading only zeroes)

- the bootloader at 133 MHz without PHY and without DMA works up to 100° C

Could be something related to PHY Tuning algorithm ?

Why in the SDK 08.05.00.24 the SBL_OSPI works with PHY disabled and in SDK 09.02.00.09 doesn't ?

Looking forward

  Andrea

  • 0
    TI__Guru 56751 points

    Hello,

    Andrea Tessadri said:
    When it comes to Bootloader_socAuthImage it will fail if we set OSPI to 166 MHz with PHY.

    Could you please enable & share the SYSFW logs to analyze the cause of the authentication failure?

    Andrea Tessadri said:
    Why in the SDK 08.05.00.24 the SBL_OSPI works with PHY disabled and in SDK 09.02.00.09 doesn't ?

    This is a known issue fixed with the following commits:

    am64x, am243x: bootloader: Fix DAC mode not enabled in ospi bootloaders · TexasInstruments/mcupsdk-core@82faf8f

    am64x,am243x: ospi: Change ReadAttackVector api to preserve dac state · TexasInstruments/mcupsdk-core@dbcc81b

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 567 points

    Hi Prashant Shivhare,

       thank you for your immediate reply.

    I have applied recommended changes to SDK 09.02.00.09 but it partially solve the issue.

    If I remove PHY from OSPI controller on SysCfg, now it works.

    Unfortunately it still fails with PHY + DMA and 166 MHz (it works only at 133 MHz).

    We cannot collect SYSFW logs because our MAIN_UART1 is unconnected.

    We have already discovered this issue with SDK 08.05.00.24 at temperature higher than 86 ° C.

    Do you think it is something related to clock correction algorithm with Attack Vector ?

    Looking forward

      Andrea

  • 0 in reply to Andrea Tessadri
    TI__Guru 56751 points

    Hello,

    Andrea Tessadri said:
    We cannot collect SYSFW logs because our MAIN_UART1 is unconnected.

    If the UART1 is not available, you may get the SYSFW logs from the memory buffer as described here. You may need debugger to save the logs from the memory.

    software-dl.ti.com/.../trace.html

    In case, you do not have debugger available, you may include this function & call it just after the Bootloader_socAuthImage to dump the logs on the same UART as used by the SBL.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    void dump_sysfw_logs()
    {
    #define SYSFW_LOGS_BUFFER_ADDR 0x44043000
    #define SYSFW_LOGS_BUFFER_SIZE 0x0FE0
    uint8_t* ptr = (uint8_t*)SYSFW_LOGS_BUFFER_ADDR;
    DebugP_log("\r\n<<SYSFW_LOGS\r\n");
    for(int32_t i = 0; i < SYSFW_LOGS_BUFFER_SIZE; i++)
    {
    DebugP_log("%c", *ptr);
    ptr++;
    }
    DebugP_log("\r\nSYSFW_LOGS\r\n");
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 567 points

    Hi Prashant Shivhare,

      thanks again for your help getting the SYSFW logs.

    Here are the logs parsed with sysfw_trace_parser.py

    The first log shows the failure case, the second shows when the bootloader is successfully authenticating the image

    We have OSPI controller with PHY enabled, DMA enabled and 166 MHz clock

    The failure case

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    <<SYSFW_LOGS - authentication
    x62000001
    0x00C2010D: BasePort: Unknown Action: 0x03 MSG:0x02010D
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    0x6180010D: Power Management: MSG_RECEIVED(TI-SCI message received): Message ID: 0x0000010D
    0x61C00052: Power Management: MSG_PARAM_DEV_CLK_ID(TI-SCI message content: dev/clk-ids): Device ID: 82 Clock ID: 0
    0x612B7C91: Power Management: CLOCK_SET_RATE(Clock Frequency has been changed: significand * 2^Exponent Hz): Clock ID: 145 Clock Frequency{significand}: 95 Clock Frequency{Exponent}: 21
    0x00C2010C: BasePort: Unknown Action: 0x03 MSG:0x02010C
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    0x6180010 C
    0x61C00052: Power Management: MSG_PARAM_DEV_CLK_ID(TI-SCI message content: dev/clk-ids): Device ID: 82 Clock ID: 0
    0x612B7C91: Power Management: CLOCK_SET_RATE(Clock Frequency has been changed: significand * 2^Exponent Hz): Clock ID: 145 Clock Frequency{significand}: 95 Clock Frequency{Exponent}: 21
    0x612B7C91: Power Management: CLOCK_SET_RATE(Clock Frequency has been changed: significand * 2^Exponent Hz): Clock ID: 145 Clock Frequency{significand}: 95 Clock Frequency{Exponent}: 21
    0x00C2C120: BasePort: Unknown Action: 0x03 MSG:0x02C120
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    FWL Bit 0x0
    Exception addr 0x45B 08000
    FWL Exception 0x1001800
    0x00070000: BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x070000
    0x44061940: Resource Management: UDMAP_GCFG_CFG(NavSS UDMAP GCFG region has been configured): Unknown Sub-Action: 0x06 MSG:0x001940
    0x00000000: BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x000000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The successfull case

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    <<SYSFW_LOGS - authentication
    x62000001
    0x00C2010D: BasePort: Unknown Action: 0x03 MSG:0x02010D
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    0x6180010D: Power Management: MSG_RECEIVED(TI-SCI message received): Message ID: 0x0000010D
    0x61C00052: Power Management: MSG_PARAM_DEV_CLK_ID(TI-SCI message content: dev/clk-ids): Device ID: 82 Clock ID: 0
    0x612B7C91: Power Management: CLOCK_SET_RATE(Clock Frequency has been changed: significand * 2^Exponent Hz): Clock ID: 145 Clock Frequency{significand}: 95 Clock Frequency{Exponent}: 21
    0x00C2010C: BasePort: Unknown Action: 0x03 MSG:0x02010C
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    0x6180010 C
    0x61C00052: Power Management: MSG_PARAM_DEV_CLK_ID(TI-SCI message content: dev/clk-ids): Device ID: 82 Clock ID: 0
    0x612B7C91: Power Management: CLOCK_SET_RATE(Clock Frequency has been changed: significand * 2^Exponent Hz): Clock ID: 145 Clock Frequency{significand}: 95 Clock Frequency{Exponent}: 21
    0x612B7C91: Power Management: CLOCK_SET_RATE(Clock Frequency has been changed: significand * 2^Exponent Hz): Clock ID: 145 Clock Frequency{significand}: 95 Clock Frequency{Exponent}: 21
    0x00C2C120: BasePort: Unknown Action: 0x03 MSG:0x02C120
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    61800100
    0x61C0008A: Power Management: MSG_PARAM_DEV_CLK_ID(TI-SCI message content: dev/clk-ids): Device ID: 138 Clock ID: 0
    0x62000000: Power Management: MSG_PARAM_VAL(TI-SCI message content: value): Target Value: 0x00000000
    0xC20 10D
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    0x6180010D: Power Management: MSG_RECEIVED(TI-SCI message received): Message ID: 0x0000010D
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The problem seams to be here:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    FWL Bit 0x0
    Exception addr 0x45B 08000
    FWL Exception 0x1001800
    0x00070000: BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x070000
    0x44061940: Resource Management: UDMAP_GCFG_CFG(NavSS UDMAP GCFG region has been configured): Unknown Sub-Action: 0x06 MSG:0x001940
    0x00000000: BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x000000
    0x00822000: BasePort: TISCI_MSG_SENDER_HOST_ID(Message from secure host received): Queue ID: 2 Host ID: 8192
    0x00000040: BasePort: INIT_COMPLETE(OSAL/Baseport init complete): MSG:0x000040
    0x20C00003: Security: SEC_BOOT(Points of failures during secure boot api call): 0x01 => Certificate length > ASN1P_IMAX, 0x02 => Issue fetching certificate, 0x3 => Issue with Hash operation, 0x4 => Hash comparison fails: 3
    8A
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

     

  • +1 in reply to Andrea Tessadri
    TI__Guru 56751 points

    Hi Andrea,

    Thanks for sharing the SYSFW logs.

    Andrea Tessadri said:
    The problem seams to be here:

    The failure signature is same as the following one for which the provided modified binaries resolved the issue.

    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1424724/mcu-plus-sdk-am243x-flash-protocol-changes-causing-problems-with-parsemulticoreappimage/5464485#5464485

    Please share the friend request I have just sent. I will share these binaries over private chat.

    Please test them once & let me know if they resolve this issue.

    Regards,

    Prashant