Dear Texas Instruments Support Team,
I'm currently working on implementing SCI bootloader using example F2837xS_SCI_Flash_kernel from C2000ware.
Issue - While trying to upload code using command in terminal. After "adjusting port settings" in terminal the process is not proceeding further which provides me a options for selecting DFU(Device Firmware Update).
Hardware Setup:
- Custom PCB with TMS320F28379S.
- RS232 Out from the TMS320F28379S is connected to an RS232-to-USB converter,
which is then connected to the PC via a USB port.
Steps Followed:
1. Uploaded SCI Flash Kernel:
- I uploaded the F2837xS_SCI_Flash_kernel code to the micro controller using the XDS110 Debugger.
2. Prepared Application Code:
- I prepared an application code for a simple LED blink.
- Converted the application code to .txt format using `hex2000` via the command line.
3. Ran the Serial Flash Programmer Command:
serial_flash_programmer_appln.exe -d f2837xS -k F2837xS_sci_flash_kernel.txt -a LED_blink.txt -b 115200 -p COM9
Terminal Output:
getting comm state
building comm DCB
adjusting port settings
After this, the process doesn't proceed further. Which gives me an option to select DFU.
Things I’ve Tried So Far:
1. Checked the COM Port:
- Verified that the RS232-to-USB converter is correctly connected and recognized as COM9 in Device Manager.
2. Checked Boot Mode of the Micro controller:
- Confirmed the GPIO pins for SCI Boot Mode are configured correctly.
- Could anyone suggest what might be causing this issue?
- What further steps can I take to troubleshoot and resolve this issue?
Thanks in advance for any assistance!
Hi Alex,
Rajamurugan,
Can you halt the CPU after issuing the run command from the host? What address is it executing from?
Best,
Alex
I'm currently working on this from my side.
Main issue: - Controller is not branching to application code after sci boot loader process.
In the meantime, could you please try to simulate the issue at your end?
If possible, I would appreciate it if you could perform all your iterations and provide a solution. Testing is taking a lot of time here, and I’m dependent on you for the next steps.
Below are the iterations I have already completed and results are in above chats.
The Flash boot (0x0B) entry point address is set to 0x80000. I have placed the application at this address as required.
Modified the linker command file to store the application code in Flash A instead of Flash B.
Updated the codestart (BEGIN) address to 0x80000.
Verified the generated .map
file — found to be correct.
Performed "1-DFU" in the serial flash programmer, followed by "6-Run" specifying the application's entry point (0x80000). (Already mentioned earlier that this was completed.)
The issue occurs only when branching to the application from the kernel, not when booting directly from flash.
Verified the contents of flash against the .out
file using the C2000 Flash Utility's "Verify Only" function — verification passed successfully.
Specified address 0x80000 when executing "6-Run" from the kernel — tested, but not working.
Branching to the application's codestart was tested as well — still not working.
Please let me know if you are able to simulate the issue and help identify a solution.
Thanks a lot for your support!
Rajamurugan,
We are working on reproducing this on our side and appreciate your patience. In the meantime, since this thread has gotten quite long, could you please open a new one?
Best,
Alex