TMS320F280041: CodeSkin program fail

Terry,

Both belong to RevB I think - There should not be any difference in BootROM.

Can they try at a lower baud if possible?  CodeSkin can help them to configure the lower baud - please suggest them to contact CodeSkin at info@codeskin.com.  They respond pretty quickly for any customer issues.  They will contact us if they need our help.   

Codeskin FAQ: https://www.codeskin.com/c2prog-faq

Thanks and regards,

Vamsi

Hi Vamsi

We try TI command line tools "serial_flash_programmer.exe -d f28004x -k flashapi_ex2_sci_kernel.txt -a led_ex1_blinky.txt -b 9600 -p COM6" from SDK "C2000Ware_3_03_00_00\utilities\flash_programmers\serial_flash_programmer" and get the same issue.

The command line can download both "flashapi_ex2_sci_kernel" and "led_ex1_blinky" ok in old batch device "YFB-07AF07W". However only the "flashapi_ex2_sci_kernel" can download ok in new batch device “YFB-15A7K1W”, then it always will halt in the middle of "led_ex1_blinky" downloading procedure.

I continue capture the SCI TX waveform in the F280041 pin, and found the baud rate is accurate 9600 in "flashapi_ex2_sci_kernel" download phase, but baud rate will change to ~3% offset than 9600 in "led_ex1_blinky" download phase. I double confirm this baud rate offset will happen in both new batch device and old batch device, and even happen in F28004x launchpad.

Because 3% offset is under margin for SCI communication, so I suspect the INTOSC offset in new batch device maybe worse than old batch device, so that new batch device SCI baud rate is also worse offset and cause communication unstable. 

I think flashapi_ex2_sci_kernel change the SCI baud rate, how do you think?  Do we have solution to download the "led_ex1_blinky" directly through F280041 internal BOOTROM without need "flashapi_ex2_sci_kernel"?

Terry,

I asked our SCI kernel expert to help you further.  

She can loop in INTOSC expert if needed and analyze this further for you.

Please expect their reply in a day or two.

Thanks and regards,

Vamsi

Terry, 

The change in baud rate may be due to the autobaud lock that occurs in the SCI flash kernel, but there is an autobaud lock with the SCI ROM bootloader as well so the autobaud lock may not be the issue. I will speak with the INTOSC expert and get back to you about your INTOSC questions. 

Thanks, 

Anu

Terry,

Would you be able to measure INTOSC from an external pin on those two sets of devices?  Here is the code to do that:

SysCtl_selectClockOutSource(SYSCTL_CLOCKOUT_INTOSC2);
SysCtl_setXClk(SYSCTL_XCLKOUT_DIV_1);
GPIO_setPinConfig(GPIO_16_XCLKOUT);

INTOSC2 will be available on GPIO16 for external measurement.

Thanks,

Joseph

Hi Joseph

 We measure INTOSC2 from GPIO16 that one device is 80ns and another is 78.5ns.  While customer setting is 100Mhz / 8.

Since this discussion is being continued offline, I will close this thread for now. If needed, feel free to open another thread or continue this one.

Thanks, 

Anu