• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 84 subscribers
  • Views 335 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.

TMS320F280039C: Firmware update via SCI succeeds on second write

Conor
Guru 10990 points
Part Number: TMS320F280039C

Hi,

A customer flashed firmware to a custom board via SCI. They were able to write by following the steps below.
1. Launch CCS
2. Press the debug button on CCS
3. Write 5AFF1820 to 0xd00
4. Write FFFF41FF to 0xd04
5. Press the Reset button on CCS
6. Press the RUN button on CCS
7. Pass arguments to write via SCI from serialFlashprogrammer.exe and execute
8. After downloading the kernel, the application becomes an infinite loop, so remove the breakpoint on CCS.


9. Press the Reset button on CCS
10. Press the RUN button on CCS
11. Stop the app once and run serialFlashprogrammer.exe again

After following this procedure, the user program writing screen was displayed after the kernel boot was started, and the writing was successfully completed. I would like to know the reason why writing failed the first time on CCS and writing can be performed normally by following the above procedure. We are also investigating whether writing can be performed without following the above steps. Do you have any advice for me?

Thanks,

Eevee

  • 0
    TI__Expert 3505 points

    Hi Eevee,

    Will loop in the SCI flash kernel experts

    Regards, Pawan

  • 0
    TI__Expert 4300 points

    Hi Eevee,

    I will review and get back to you.

    Regards, 

    Rajeshwary

  • 0 in reply to Rajeshwary Nitin Bongirwar
    Guru 10990 points

    Hi, Rajeshwary, Pawan

    Do you have any update?

  • 0 in reply to Conor
    TI__Genius 11815 points

    Hi Eevee,

    Back to the forums. In the device.h header file, have you tried to change the SCI pins to 8 and 9 respectively? If you do, make sure to comment out the usage for GPIO pins 8 and 9 previously (set to SPI usage). 

    On CCS side, allow the sciGetFunction to take in SCI_BOOT_ALT2 as a parameter (GPIO8 and GPIO9 will be used). As for using CCS, the reason it is getting stuck at autobaud lock is because the Serial Flash Host programmer cannot use the COM port as JTAG is currently using it through CCS. To test with CCS, make sure to use the serial_flash_programmer_appln.exe. 

    Thanks,

    Charles

  • 0 in reply to Charles Roberson
    Guru 10990 points

    Hi, Charles

    As a result of the above procedure, the following screen was displayed. Can you give me any advice?

    Thanks,

    Eevee

  • 0 in reply to Conor
    TI__Genius 11815 points

    Have you tried increasing the baud rate above 9600? The NACK error indicates that the correct amount of packets are not being sent to the device. If possible, could you attach GPIOs 8 and 9 to an serial viewer to see what packets are being sent and where it stops? Once the kernel starts to run, the PLL is configured for a higher clock speed, which may be affecting the custom board. Will continue to look into resolving this issue.

    Thanks,

    Charles

  • 0 in reply to Charles Roberson
    Guru 10990 points

    Hi, Charles

    I captured the signal in the bus when serial_flash_programmer_appln.exe was executed and displayed it using the bus analysis function.
    Could you please check the attached excel file? I tried two baud rate patterns, 9600bps and 19200bps.
    The MCU is responding correctly to the first signal, but from the second signal the MCU seems not to respond.

    SCI bus signals.xlsx

    Thanks,

    Eevee

  • 0 in reply to Conor
    TI__Genius 11815 points

    Hi Eevee,

    I do see that the SCI RX only takes in two bytes before stopping transmission. On the TX line, is the transmission occurring over GPIO29 or GPIO8?

    Will follow up a bit later. 

    Thanks,

    Charles