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.

TMS320F28379D: SCI programming stuck on attempting Autobaud

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hello,

I am trying the test the sci flash programmer for F28379D controlCARD R1.3 and controlCard DOcking Station R4.1.

I am using C2000Ware3.4 and the precompiled executables and .txt hex files at C2000Ware/utilities/flash_programmers/serial_flash_programmer

I have connected win10 host computer via usb to uart ftdi converter cable to GPIO84/85. I have tested this serial connection using the c2000ware sci echoback example with necessary pin mux changes. I am able to echo characters back succefully using putty connected to the COM port.

I have tried to put the card into SCI boot mode via the dip switch A:SW1 on the controlCARD. it is set to 01. 

In order to program I run the following command in the console and autobaud fails to lock

I've seen many other questions on this board which usually are due to a bad serial connection or wanting to use GPIO28/29 for connection. I know my serial conneciton works and I'm trying to use default pins. What could be cauing autobaud to not lock?

I have probed the pins on the experimenter kit with a signal analyzer. I could see the host send 'a' once then no other activity on either serial line.

Please advise!

  • Hello, 

    With the controlCARD, you will need to use the alternate SCI Boot pins in order to download the flash kernel. Please refer to the F2837x section of the FAQ of the following app note: https://www.ti.com/lit/an/sprabv4e/sprabv4e.pdf 

    The screenshot below shows how to run the example with the F2837x controlCARD: 

    Thanks,

    Anu

  • Anu,

    This did resolve my issue. thank you for pointing me to the errata. However the Technical Reference Manual for F2837xD says SCI boot from GPIO28/29 only allows CPU1 support. is there a known way to flash CPU2 using these gpios.

    As a follow up, if I were to implement my own flash kernel can any set of gpio's be used to serially flash both cpus or are there hardware limitations restricting use of flash memory based on serial config. I know I would have to flash my kernel to the device via entering sci boot, reseting and using gpio 28/29. But could my kernel then recieve the data to flash a new program over another sci interface? The end result of this architecture would be to have the custom flash kernel embedded in an existing program which would receive a serial command to branch into the kernel wherein it would wait for firmware update of both cores then reset both.

  • Got CPU2 to flash using gpio28/29 and alt kernel. Process was slightly different then that detailed in sprabv4e.pdf and based on my understanding of the TRM shouldn't have worked.

    1. Set A:SW1 to On, On; SW1 to 0,1

    2. Connect CPU1 in CCS, Connect CPU2 in CCS

    3. Modify 0xD00 to 0x815A in CPU1. Modify 0xD00 to 0x815A in CPU2

    4. Reset CPU1, Reset CPU2

    5. Resume CPU2. Wait for ESTOP at 0x3FE44E, Resume CPU2 again.

    6. Resume CPU1

    7. Run serial_flash_programmer.exe -d f2837xD -k kernel_01_alt.txt -a blinky_01.txt -m kernel_02.txt -n blinky_02.txt -p COM14 -b 9600

    8. DFU CPU1; Run CPU1 and boot CPU2; DFU CPU2; Run CPU2