• State TI Thinks Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 29 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 592 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.

MCU-PLUS-SDK-AM243X: Fails 60-80% when writing HS-SE conversion key writer via usb_dfu_uniflash.py other flash writers work consistently.

Mark Ward
Prodigy 110 points
Part Number: MCU-PLUS-SDK-AM243X
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

We have been attempting to use usb_dfu_uniflash.py to write a HS-SE conversion key writer to AM243x MCU with inconsistent results.

If we write the same key writer to the MCU via uart_uniflash.py, it works consistently.

We have tested this on three setups and four different board. In the best case this fails 6 out of 10 times. It fails more often on other boards and setups, realizing that 10-30 attempts isn't a large statistical sample.

When we make the attempt it is part of a provisioning script that we have written for our product that first erases the MCU (if not already found erased). The erase status is determined by using dfu-util -l and looking to see that USB path is returned for our device:

Fullscreen
1
2
3
4
5
6
7
8
9
10
09:49:14 592 [INFO] Results of script:
dfu-util 0.11
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Found DFU: [0451:6165] ver=0200, devnum=15, cfg=1, intf=0, path="3-1.2.2.4", alt=1, name="SocId", serial="01.00.00.00"
Found DFU: [0451:6165] ver=0200, devnum=15, cfg=1, intf=0, path="3-1.2.2.4", alt=0, name="bootloader", serial="01.00.00.00"
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The script then writes to the MCU using usb_dfu_uniflash.py, this script does not fail. Example of output from logs below.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
09:49:14 594 [INFO] Executing script: /Users/markwar/workspace/calamari/calamari/am243x/usb_dfu_uniflash.py --cfg /Users/markwar/workspace/calamari/tmp_conv_3-1.2.2.4_cu.usbserial-312300.cfg -p 3-1.2.2.4 and expecting "All\ commands\ from\ config\ file\ are\ executed" (RegEx)
09:49:14 594 [INFO] Script start ----------------------------------------
09:49:16 183 [INFO] Results of script:
dfu-util 0.11
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0451:6165
Device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

After the above using usb_dfu_uniflash.py script is run we look at the UART output of the MCU. Most commonly we see the MCU fail to finish booting. It doesn't hang at the same place in all cases, but the example below is the most common place we see it hang.

Fullscreen
1
2
3
Starting Keywriting
Set GPIO0_74 high to enable VPP 1.8v
Please ent
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

In less common cases it looks the MCU boots and we get the sbl_keywriter # prompt, but the MCU hangs in response to the START_PROGRAM_KEY command. Again not always in the same place, so here are a few examples of the output we see from our logs when we make the attempt.

Fullscreen
1
2
3
sbl_keywriter # START_PROGRAM_KEY
Start programming OTP keys:
keys Certificate found: 0x70052600
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Fullscreen
1
sbl_keywriter # START_PRO
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Fullscreen
1
2
3
sbl_keywriter # START_PROGRAM_KEY
Start programming OTP keys:
keys Certificate found: 0x'
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

When this works we see the following output.

Fullscreen
1
2
3
4
5
6
sbl_keywriter # START_PROGRAM_KEY
Start programming OTP keys:
keys Certificate found: 0x70052600
Keywriter Debug Response:0x0
Success Programming Keys
Set GPIO0_74 low to disable
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Again to be clear about the question: Has TI tested this HS-SE conversion key writer when loaded via both UART and USB?

What can I do to make this process reliable via USB?

  • 0
    Prodigy 110 points

    I forgot an important piece of information to add to this ticket. I have no problem using usb_dfu_uniflash.py as a flash writer via USB for our application code, we do not use the same flash writer for both USB and UART, but our provisioning script supports both means to write flash. Thus I think we know that the USB port on our device works well, thus we believe the hardware is good.

    This seems to be either a failure of our key writer firmware to work for USB (but it does work when written to the MCU via UART) or a failure of usb_dfu_uniflash.py to support writing the key writer to the MCU.

    My co-worker will describe her changes to the key writer code.

  • 0 in reply to Mark Ward
    Intellectual 737 points

    The only change we made on TI's keywriter is to add:
    1) Toggle the VPP voltage via a GPIO before programming the key and after the key is programmed. 
    2) Add a simple cmd line interface, to allow the user to type a command to start programming the key. 

    Note the exact same binary runs well when using UART boot, but it is not stable after switching to USB boot.  We didn't expect to see the difference between different boot modes here. 

    The failure behavior here is the same on the USB boot case after disabling UART0 ISR in the keywriter, suggested by Prashant in another thread. 

    Thanks, 
    Hong 

  • 0 in reply to Hong Zhang
    Intellectual 737 points

    I went back to test the keywriter binary directly built from the release. Only commented out the two line to setVPP, because we don't have the same part on our board. I noticed the difference between UART boot and USB boot. 

    UART boot, it failed due to the VPP was not set. 

    Fullscreen
    1
    2
    3
    4
    Starting Keywriting
    keys Certificate found: 0x70046500
    Keywriter Debug Response:0x20000000
    Error occured...
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    USB boot, it hang at early stage as below. 

    Fullscreen
    1
    2
    Starting Keywriting
    keys Certificate found: 0x7004
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    Note that the keywriter version here is from SDK 9.1's release.  

    Thanks, 
    Hong 

  • 0 in reply to Hong Zhang
    TI__Guru 57651 points

    Hi Hong,

    The failure signature strongly suggests the UART Interrupt issue. Could you please share how did you disable the UART Interrupt mode in the keywriter?

    If possible, please share the keywriter syscfg file.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 737 points

    Hello Prashant, 

    Here is the change to disable UART0 ISR, 



    I also repeated the same failure using keywriter from SDK10's release later last night with USB boot.  The failure behavior is exactly the same. 

    Thanks, 
    Hong 

  • 0 in reply to Hong Zhang
    Intellectual 737 points

    Hello Prashant, 

    I was able to reproduce the same issue on TI's EVM, and here is the capture using JTAG 

  • 0 in reply to Hong Zhang
    TI__Guru 57651 points

    Hi Hong,

    The call trace suggests the UART driver waiting for data to be read. Are you not able to input anything on the console?

    Have you tried commenting the DebugP_scanf & still see the issue?

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 737 points

    Hello Prashant, 

    When I captured the above screenshot using JTAG, I was not able to input anything on the console. UART already hang.  

    I have not tried commenting out the DebugP_scanf yet.

    I think this information is enough for TI to reproduce on TI side using TI EVM, given this is not limited to our board. 

    Thanks, 
    Hong 

  • 0 in reply to Hong Zhang
    Intellectual 737 points

    I do see DebugP_scanf is used by other SDK examples. And it calls UART_read internally. I don't see any issues that should be caused by the DebugP_scanf here. 

    We need to receive input command from UART interface, so we cannot bypath this. Instead, could TI help to understand why the DebugP_scanf hangs in the ti's keywriter when using USB boot mode? 

    Thanks, 
    Hong 

  • 0 in reply to Hong Zhang
    TI__Guru 57651 points

    Hello,

    I enabled the DebugP_scanf with the following patch:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    diff --git a/source/security/sbl_keywriter/am243x-evm/r5fss0-0_nortos/main.c b/source/security/sbl_keywriter/am243x-evm/r5fss0-0_nortos/main.c
    index 02679a82..7f8237b9 100644
    --- a/source/security/sbl_keywriter/am243x-evm/r5fss0-0_nortos/main.c
    +++ b/source/security/sbl_keywriter/am243x-evm/r5fss0-0_nortos/main.c
    @@ -51,7 +51,7 @@ void loop_forever(void)
    int32_t main(void)
    {
    int32_t status = SystemP_SUCCESS;
    -
    + uint8_t flag = 0;
    #if defined(COMBINED_BOOT_MODE)
    status = Bootloader_socWaitForFWBoot();
    @@ -82,11 +82,19 @@ int32_t main(void)
    status = Sciclient_getVersionCheck(1);
    + while(flag != 'y')
    + {
    + DebugP_log("Press 'y' to program certificate: ");
    + DebugP_scanf("%c", &flag);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    and did not see any issues for 50 runs of the keywriter binary (tiboot3.bin).

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    [13:18:07.814] Combined boot mode
    [13:18:07.814] Starting Keywriting
    [13:18:07.814] Enabled VPP
    [13:18:07.814] DMSC Firmware Version 10.0.8-v10.00.08_am64x_keywrite
    [13:18:07.830] DMSC Firmware revision 0xa
    [13:18:07.830] DMSC ABI revision 4.0
    [13:18:07.830] Press 'y' to program certificate: y
    [13:18:09.126] keys Certificate found: 0x7001b980
    [13:18:09.318] Keywriter Debug Response:0x0
    [13:18:09.318] Success Programming Keys
    [13:18:09.320] DONE!!!
    [13:18:14.245] Combined boot mode
    [13:18:14.245] Starting Keywriting
    [13:18:14.246] Enabled VPP
    [13:18:14.246] DMSC Firmware Version 10.0.8-v10.00.08_am64x_keywrite
    [13:18:14.261] DMSC Firmware revision 0xa
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Please provide your keywriter binary or provide the keywriter patch for me to reproduce the issue locally on the TI EVM.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 737 points

    Hello Prashant, 

    Could you please let me know what is your setup to run repeated testing?  For USB boot, I think a power cycle or reset is required to be able to load for next round. Do you in case use USB boot for the above test?  And does the keywriter actually programming keys?


    I might have been very lucky to be able to reproduce the issue as above on EVM board. I did run several tests today with the same binary, and I was not able to reproduce the same issue on my side using EVM. 

    The only difference from our side code and your code snip is that we used a %s instead of %c on your side. 

    int ret = DebugP_scanf("%s", cmd);

    Thanks, 
    Hong 


  • 0 in reply to Hong Zhang
    TI__Guru 57651 points

    Hi Hong,

    I indeed boot the keywriter in the USB DFU bootmode. The repeated boot is done by manually powering off/on the EVM & inputting the 'y' character. The keywriter certificate is generated with the following command:

    Fullscreen
    1
    ./gen_keywr_cert.sh -t tifek/ti_fek_public.pem --msv 0xC0FFE --msv-ovrd
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Even with an automated setup, I did not see any issues for about 1800 runs of the keywriter binary.

    ====================

    Prashant Shivhare said:
    I enabled the DebugP_scanf with the following patch

    I do see random failures with this patch on the Keywriter v09.01.00 which configures the UART0 in Interrupt mode by default. However, if the mode is changed to polling mode, I haven't seen any issues even after about 6900 runs of the keywriter binary.

    ====================

    In short if the UART is configured in polling mode, I haven't seen any issues in both the keywriter versions.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 737 points

    Hello Prashant, 

    Could you please help to test using an input string "START_PROGRAM_KEY" with echo to print this string out instead of using one char as above?


    Fullscreen
    1
    int ret = DebugP_scanf("%s", cmd);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    That is the only difference that I can see between our side and your side. 

    Thanks, 
    Hong 

  • 0 in reply to Hong Zhang
    Intellectual 737 points

    Hello Prashant, 

    I was able to reproduce on TI's EVM using keywriter 9.1 as well with UART ISR disabled on UART0.  The above repro with JTAG capture was on SDK 10's keywriter. This capture is on SDK 9.1's keywriter. 

    It failed the same way as below. The UART0 hangs now 

  • 0 in reply to Hong Zhang
    Intellectual 737 points

    Hello Prashant, 

    I dumped the UART register values as below, could you please help to double confirm whether the ISR is disabled as expected?

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    0x027FFEE0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    0x027FFF40 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    0x027FFFA0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    0x02800000 UART0_MEM_DLL, UART0_MEM_RHR, UART0_MEM_THR
    0x02800000 00000000
    0x02800004 UART0_MEM_DLH, UART0_MEM_IER_CIR, UART0_MEM_IER_IRDA, UART0_MEM_IER_UART
    0x02800004 00000000
    0x02800008 UART0_MEM_EFR, UART0_MEM_FCR, UART0_MEM_IIR_CIR, UART0_MEM_IIR_IRDA, UART0_MEM_IIR_UART
    0x02800008 000000C1
    0x0280000C UART0_MEM_LCR
    0x0280000C 00000003
    0x02800010 UART0_MEM_MCR, UART0_MEM_XON1_ADDR1
    0x02800010 00000000
    0x02800014 UART0_MEM_LSR_CIR, UART0_MEM_LSR_IRDA, UART0_MEM_LSR_UART, UART0_MEM_XON2_ADDR2
    0x02800014 00000060
    0x02800018 UART0_MEM_MSR, UART0_MEM_TCR, UART0_MEM_XOFF1
    0x02800018 00000000
    0x0280001C UART0_MEM_SPR, UART0_MEM_TLR, UART0_MEM_XOFF2
    0x0280001C 00000000
    0x02800020 UART0_MEM_MDR1
    0x02800020 00000000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Thanks, 
    Hong 

  • 0 in reply to Hong Zhang
    TI__Guru 57651 points

    Hello,

    I do see the issue when using the "START_PROGRAM_KEY" string as input however that's only when the string is copy pasted on the UART console. If the string is manually typed character by character, I haven't seen any issues.

    With the automated setup where the string is automatically typed character by character, I haven't seen any issues even after about 250 runs of the keywriter. Here are the logs for verification:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    �
    Starting Keywriting
    Enabled VPP
    Please enter 'START_PROGRAM_KEY' to continue
    # START_PROGRAM_KEY
    keys Certificate found: 0x70052e00
    Keywriter Debug Response:0x0
    Success Programming Keys
    DONE!!!
    Starting Keywriting
    Enabled VPP
    Please enter 'START_PROGRAM_KEY' to continue
    # START_PROGRAM_KEY
    keys Certificate found: 0x70052e00
    Keywriter Debug Response:0x0
    Success Programming Keys
    DONE!!!
    Starting Keywriting
    Enabled VPP
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    So, I do not think this is a target side issue. The issue is most possibly coming from how the string is entered on the UART console.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Intellectual 737 points

    Hello Prashant, 

    I am glad to know that you had a successful repro on your side.  For the copy-paste hang case, could you please help us to understand the root cause?  We have command-line interface support for our app FW as well using the same AM243 MCU and we have not seen this copy-paste hang issue at all. This issue only happened for the keywriter.  

    From the above Mark's reported failure case, the UART print can hang at anywhere not only limited to the place during DebugP_scanf is receiving input. I hope by understanding the rootcause here can help us to address other hang case as well for the keywriter. 


    Thanks, 
    Hong

  • 0 in reply to Hong Zhang
    Intellectual 737 points

    Hello Prashant, 

    There is one more questions regarding the FIFO_EN bit. 

    Based on AM243 TRM, FIFO_EN needs to be set to be 0 for the FIFO polled mode operation. 

     12.1.5.4.6.3 FIFO Polled Mode Operation
    In FIFO polled mode (the UART_FCR[0] FIFO_EN bit is set to 0 and the relevant interrupts are disabled by the
    UART_IER_UART register), the status of the receiver and transmitter can be checked by polling the line status
    register (UART_LSR_UART).
    This mode is an alternative to the FIFO interrupt mode of operation in which the status of the receiver and
    transmitter is automatically determined by sending interrupts to the Host CPU.

    While in SDK uart drivere's uart_v0_lld.c file, I see FIFO_EN is always set to be 1 for SDK 9 and SDK 10.  

        /* Enable FIFO */
        fcrValue |= UART_FCR_FIFO_EN_MASK;

    Could you please help me to understand whether the UART is operating at FIFO polled mode with this FIFO_EN bit setting to be 1 from the SDK? 

    Thanks, 
    Hong 
  • 0 in reply to Hong Zhang
    TI__Guru 57651 points

    Hello,

    Hong Zhang said:
    For the copy-paste hang case, could you please help us to understand the root cause?

    The DebugP_scanf function is designed to receive & echo the input character by character.

    https://github.com/TexasInstruments/mcupsdk-core/blob/next/source/kernel/nortos/dpl/common/DebugP_uartScanf.c#L40-L40

    So, while copy pasting the whole string on the UART console, the data is possibly getting lost in polling mode resulting in the UART driver forever waiting for the further input.

    Could you please try a shorter string as input like SPK (for START_PROGRAM_KEY) as input & see if the issue still occurs?

    I have tried it on TI EVM & do not see any issues.

    So far, I have seen issues for the following cases only:

    • Keywriter v09_01_00 with UART in Interrupt mode (default) results in random failures when taking input.
    • Keywriter v09_01_00 and v10.00.08 in Polling mode results in consistent failures when taking larger string as input. The failure only occurs when copy pasting the whole string.
      • No issues seen when typing string character by character.
      • No issues seen when copy pasting for string upto 3 - 4 characters.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Guru 57651 points

    And,

    Prashant Shivhare said:
    Keywriter v09_01_00 with UART in Interrupt mode (default) results in random failures when taking input.

    This is a generic UART interrupt issue.

    Prashant Shivhare said:
    Keywriter v09_01_00 and v10.00.08 in Polling mode results in consistent failures when taking larger string as input. The failure only occurs when copy pasting the whole string.

    This is seen even in the SBL NULL bootloader

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    [17:35:21.797] Starting NULL Bootloader ...
    [17:35:21.797] DMSC Firmware Version 9.1.6--v09.01.06 (Kool Koala)
    [17:35:21.813] DMSC Firmware revision 0x9
    [17:35:21.814] DMSC ABI revision 3.1
    [17:35:21.814] Please enter 'START_PROGRAM_KEY' to continue
    [17:35:21.814] # START_PR
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    In short, there is nothing keywriter specific issue I have seen till now.

  • 0 in reply to Prashant Shivhare
    TI__Guru 57651 points

    Last update for the day:

    Prashant Shivhare said:
    This is seen even in the SBL NULL bootloader

    The issue is not seen in the SBL NULL bootloader from SDK v09_00_00_35.

    So, I ported the UART driver from this SDK version to SDK v09_01_00_41, then I haven't seen the following issue.

    Prashant Shivhare said:
    Keywriter v09_01_00 and v10.00.08 in Polling mode results in consistent failures when taking larger string as input. The failure only occurs when copy pasting the whole string.
  • 0 in reply to Prashant Shivhare
    Intellectual 737 points

    Hello Prashant, 

    Thanks for the help to understand the questions here. 

    From what I understand, UART has FIFO size of 64 bytes for both TX and RX. I don't understand why DebugP_scanf cannot handle receiving character and echo it back fast enough for only 10+ characters. I did try to increase the rxTriggerLevel to see whether it makes difference, but I didn't have luck here. 

    In our use case, we don't use copy-paste, but we have python script to handle sending characters of START_PROGRAM_KEY. This failed the same way as the copy-paste example you have as above on EVM board. 

    I also have the above questions regarding FIFO_EN setting in SDK's uart_v0.c, which seems to be conflict with TRM's recommendation for UART polling mode. I believe, with a proper setting, AM243x with a 800 MHz MCU clock frequency should be able to handle receiving and echoing a character back properly at UART clock of 115k; unless there is something else that we have not understood about. 

    Thanks, 
    Hong 

  • 0 in reply to Hong Zhang
    TI__Guru 57651 points

    Hi Hong,

    Prashant Shivhare said:
    Keywriter v09_01_00 and v10.00.08 in Polling mode results in consistent failures when taking larger string as input. The failure only occurs when copy pasting the whole string.

    I have identified the root cause of this bug. It is apparently caused by the incorrect handling of the remaining data to be read in the UART_fifoRead function.

    Please try the following patch & let us know if the issue still occurs:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    diff --git a/source/drivers/uart/v0/lld/uart_v0_lld.c b/source/drivers/uart/v0/lld/uart_v0_lld.c
    index 0b4b10c..8b96376 100644
    --- a/source/drivers/uart/v0/lld/uart_v0_lld.c
    +++ b/source/drivers/uart/v0/lld/uart_v0_lld.c
    @@ -2460,7 +2460,7 @@ static uint32_t UART_fifoRead(UARTLLD_Handle hUart, uint8_t *buffer,
    isRxReady = UART_statusIsDataReady(hUart);
    - while (((Bool)TRUE == isRxReady) && (0U != readSizeRemaining))
    + while (((Bool)TRUE == isRxReady) && (0U != tempReadSizeRemaining))
    {
    /* once the H/w is ready reading from the H/w */
    *tempBuffer = (UInt8) UART_readByte(hUart);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I do not see issue for copy pasting after applying the patch.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Guru 57651 points
    Prashant Shivhare said:
    I have identified the root cause of this bug. It is apparently caused by the incorrect handling of the remaining data to be read in the UART_fifoRead function.

    This is already fixed in the SDK v10_01_00_32 with the following patch

    am263x: uart: Fix the uart read issue · TexasInstruments/mcupsdk-core@0cf5573

  • 0 in reply to Prashant Shivhare
    Intellectual 737 points

    Hello Prashant, 

    Very glad to know that the root cause has been identified. 

    We have been using the released library from SDK directly.  For applying the above patch for SDK, does it mean that we need to re-build the library drivers.am243x.r5f.ti-arm-clang.debug.lib?

    Thanks, 
    Hong 

  • 0 in reply to Hong Zhang
    TI__Guru 57651 points
    Hong Zhang said:
    For applying the above patch for SDK, does it mean that we need to re-build the library drivers.am243x.r5f.ti-arm-clang.debug.lib?

    That is correct.

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

  • 0 in reply to Prashant Shivhare
    TI__Guru 57651 points

    Hi Hong,

    Please let us know if the issue is resolved and no further support is needed.

    Thanks!

  • 0 in reply to Prashant Shivhare
    Intellectual 737 points

    Hello Prashant, 

    Thanks for checking. 

    This issue has been resolved with the patch for the SDK UART driver. 

    This can be closed. 
    Hong 

  • 0 in reply to Hong Zhang
    TI__Guru 57651 points

    Thanks for the clarification, Hong.

    Closing the following one too:

    e2e.ti.com/.../am2432-after-programming-otp-tisci_msg_flag_ack-flag-is-not-received