TMS320F280049C: Ensuring Correct SCI Flash Kernel Loading to RAM and Behavior

Hi Ankur, 

1. 5 seconds should be long enough. 

2. The character looks correct. 

3. The examples usually use 9600, but 4800 should be ok. 

4. Looks like the header and footer have the LSB and MSB switched. The LSB needs to be sent before the MSB. The checksum also needs to include the data sent along with the Erase command. If there are errors during transmission, the kernel returns a NAK. Before that though, if the autobaud lock is not occurring, the packet you are transmitting probably isn't making it to the kernel. 

5. Did you make any changes to the kernel example when using it on your custom board? Were you able to run the example without issues on a ControlCard or launchpad? Knowing what changes were made if any will help pinpoint the issue. 

Thanks, 

Anu

Hi Anu,

Thanks for your response!

We haven't tried on the Launchpad board, but I don't believe we've changed the example, other than configuring it to CPU1_RAM.

Best Regards,

Ankur Aggarwal

Ankur,

Thank you for the info.

Anu is OOO today.  She will get back to you in a day or two.

Thanks and regards,
Vamsi

Hi Ankur, 

What is your clock source on your custom board?

You can try the following two things: 

1. Run the flash kernel example on a launchpad or CC and see if you get any issues. 

2. Run the sci_ex4_echoback example with your custom board and have the autobaud lock enabled. This will help narrow down whether autobaud lock is working. 

Thanks, 

Anu

Hi Anu,

Thanks again for your response!

1. We use the internal oscillator of the TMS320F280049C chip itself.

2. The strange thing about the autobaud lock is that it only seems to work with the built-in bootloader that's already in the ROM, but not with the flash kernel once that appears to have been loaded into RAM. Is that something you've seen before, and have recommendations on how to fix?

3. I'm going to look into setting this up on our Launchpad boards. In the mean time, can you please let us know if these are the appropriate parts for the CC solution?

https://www.mouser.com/ProductDetail/Texas-Instruments/TMDSHSECDOCK?qs=%2Fha2pyFadujs5cHMYWRkT4lBSTb4GdS9V2O%2FdrqvzmkSOjF%252BEpsZ%252Bg%3D%3D

https://www.ti.com/tool/TMDSCNCD280049C#supported-products

These two seem to be in stock.

I also found this unit being recommended for serial connections:

https://www.ti.com/tool/TMDSFSIADAPEVM#included

However, this one is not in stock. Do you think it is strictly required, if we already have a custom host control board from which we can wire over UART signals?

Best Regards,

Ankur A.

Ankur, 

The example is configured to run with the external oscillator. You can change the clock source in the example to run with the internal oscillator, this may help resolve your issue. Section 3.7.11 of the TRM shows how to configure the INTOSC as the clock source.

The CC and docking station look fine, you do not need the additional resource you linked. 

Thanks, 

Anu

Anu, 

This clock issue was a huge find! I'm able to do some basic GPIO toggling after making what looks like the changes recommended in that section you indicated, so that's definitely progress that helps me move forward.

If you don't mind, I'm going to continue to keep this channel open just in case I run into further issues, but this is definitely the right start! 

Best Regards,

Ankur Aggarwal

Ankur, 

Glad you are able to make some progress, and sure if you have further flash kernel related issues you can post them here, if they are related to something else go ahead and start a new thread. 

Thanks, 

Anu

Hi Anu,

So I'm able to load what I think is a working flash kernel over UART. As I send data over it, though, the behavior I get back, as shown in the image, is a little strange:

1) I see the autobaud character echoed,

2) then I send the packet, 3) then I receive 0xA5,

4) then a long time later (100ms?), well after I send the second packet, I just get the header byte echoed

5) ~30-45ms later after the header, I receive what looks like the status packet.

Is this right? If not, what should I actually be expecting, and what might likely explain the observed behavior on the logic analyzer?

Best Regards,

Ankur Aggarwal

Quick Update:

As you can see, I can now get a status packet with an address of 0x12345678, which according to the document appears to be a good thing. However, I'm not 100% sure how to interpret the earlier part of the packet, after the header and length (0x65 0x00 0x00 0x50).

Also, what does it mean to get a NAK instead of an ACK as a response?

Best Regards,

Ankur A.

Ankur, 

What commands are you sending in the first screenshot? 

In the second screenshot, after the header and length are sent by the kernel, the command and status are sent, this is likely what you are seeing. 

If a NAK is received, it means that some portion of a packet may not have been received by the host correctly. 

Thanks, 

Anu

Hi Anu,

Thanks for your response!

In both instances, I'm attempting to send an erase command to CPU1.

However, if I'm seeing both a NAK and a 0x5000 for status, that tracks that there may be an error. But then how can I be receiving 0x12345678 for address?

Also, I don't see how my command is being reflected in the received packet? 0x0065 does not correspond to any of the commands per this document:

http://file.elecfans.com/web1/M00/00/0E/o4YBAFnLrxKATROGAAYPkh4x3QU718.pdf

I'm wondering if any timing issues are lingering. Do you have any recommendations on how to sanity check that I configured my clock correctly? Furthermore, do you have any other thoughts on what might be happening?

Best Regards,

Ankur

Ankur, 

I will check with a clock expert on what checks you can perform to make sure the clock is configured correctly and get back to you in a day or so. I am not really sure why the behavior you described is occurring, have you been able to run the example on a CC and see what the logic analyzer shows? Is your host side sending commands in the same manner that the host side programmer in C2000Ware is?

Thanks, 

Anu

Update:

I am finally able to get a proper ACK character. The issue was my checksum computation.

Best Regards,

Ankur

Further update:

When I send the DFU command (total length of 10, data length of 0, since data comes after), I get an 0xA5 (NAK). Is my packet constructed correctly?

Best Regards,

Ankur

Sorry, here's the image:

Ankur, 

Can you share what your clock configuration looks like? After changing the clock source to the internal oscillator, did you change your IMULT value accordingly? 

For your question regarding the DFU command, it looks correct. In general for sending commands, are you following the functions found in the serial_flash_programmer utility? You can find the source code for the utility in C2000Ware_x_xx_xx_xx\utilities\flash_programmers\serial_flash_programmer\serial_flash_programmer\source. 

Thanks, 

Anu

Hi Anu,

My clock configuration is as follows:

Ankur, 

The Run packet looks correct. 

After each command, the kernel sends back a packet with information about the packet. To see how the host side receives this packet, you can refer to the getPacket function found in f021_SendMessage.cpp in the source files for the serial_flash_prgrammer host utility found in C2000Ware. The host side just takes in the data from the kernel and prints to the console if errors were detected in the packet. 

For the clock configuration, what clock frequency are you aiming for?

Thanks, 

Anu

Hi Anu,

I guess the clock speed I  was going for was 100MHz? Not super committed to that particular number, though.

I guess to be more specific, do I need to Ack every checksum that comes back from the kernel?

More broadly, I'm sending the entire application, followed by 00 (as shown), followed by the run packet, but the application is not in fact running. Assuming the application file has been constructed correctly, what is the next place to look as far as debugging is concerned?

Thanks,

Ankur

Ankur, 

The application file should have the block of 00 00 at the end of the file needed to signal to the kernel that the file transmission is complete. There should be no need to send another 00 from the host between the application and the run command. Once the application is finished being transmitted, the kernel should send a status packet. As a part of this status packet, there will be checksums sent and after each byte of the checksum, the kernel waits for an ACK. On the host side in the programmer utility, the checksum is received in bytes and after each byte, the host sends an ACK. 

To check whether the clock speed is at 100 MHz, you can check whether the values you are plugging into the DEVICE_SETCLOCK_CFG value equal 100 MHz. The formula should be commented above the define. 

Thanks,

Anu

In addition, have you had the chance to run the example on a CC? That will be a good baseline to compare your program against and will help with pinpointing any transmission issues you are having since you can set breakpoints on the target and host side. 

Thanks, 

Anu

I just got the Control Card today and tried using it. I've configured the S1:A and S1 switches as shown in the image (what the documentation suggests is required for UART communication).

But when I try the command, I get stuck during autobaud, even though pin 76 (SCIRX) on the docking station pulls high according to the oscilloscope!