Linux/TMS320F28377D: SCI boot mode test from IMX6(Linux) to 28377 cpu1

Yi,

what are the values in your baud rate register during passes and failures?

I see that you have a comment in your code that says "// Autobaud currently fails for rates > 38400", does autobaud work at lower baudrates? How slow is your slew rate? Note: slow slew rates will cause the autobaud to miscalculate at higher frequencies.

Regards,
Cody

Hi Cody,

Thanks a lot for your reply. But I don't know where to find the baud rate register value you mentioned. Since I tried to test the SCI boot mode for DSP(28377d), there is no JTAG debugger connected to dsp. All results or outputs I can see are from linux terminal.

As for lower baudrate setting, it is from another colleague's code and I did not modify that part. He said that at higher baudrates, autobaud lock failed even if only sending one 'A'. According to reference manual, lower baudrate is preferable to compensate for slow slew rate. So I assume lower baudrate should be good in that case.

I would appreciate it if you can give some hints on how to find these values.

Best,

Yi

Yi,

all of the information about the SCI module can be found in the TMS320F28377D Technical Reference Manual. The baud rate registers are "SCIHBAUD" and "SCILBAUD" and can be found in sections 19.14.2.3 and 19.14.2.4.

Regards,
Cody

Cody,

Do you mean that I can still get access to register in debug mode through debugger, even if under SCI boot mode?

Yi,
I had assumed that you were seeing this issue with all SCI communications, not just when loading code through the SCI bootloader. That is OK, as a test you should load the Echoback test case from ControlSuite and communicate through SCI. You can experiment with this setup, figure out what baud rates are reliable for your exact setup. This will ensure that you have worked out any potential hardware bugs.

If all is working well, then you will have to start debugging the software.

Regards,
Cody

Cody,

Do you mean going back to normal SCI communication instead of SCI bootload? But in Linux side, I programmed for bootmode case not normal SCI communication, and that is the case I want to test. I assume that in SCI boot mode, dsp can echo back characters without setting registers for it, right? Because in the example code for SCI boot, the normal process is checking autobaud with 'A' echoing back, then downloading real application program. What I intend to do is sending and echoing back more characters after 'A' in a similar way, to verify hardware connection for SCI boot mode. Since I can succeed in sending 2 more characters, I thought it was feasible but something else needs to be set. I wonder if there is a way to test from linux side without setting dsp up for normal SCI communication.

My description may be not that clear. Please let me know if there is any confusion.

Best,
Yi

Yi,
To answer your questions, yes I am suggesting you first test a basic SCI example. Secondly yes, the DSP should echoback characters sent to it while using the SCI Bootloader.

I recognize that you would like to test the SCI bootloader, since this has failed and we do not know why I have suggested you to try a simpler use case for the device. If the simpler code is able to communicate reliably with your terminal, then we know positively that this is not caused by your hardware setup, and can begin to look at other possible causes.

Regards,
Cody

Cody,

Ok I got you this time. But what I am worried about is if it is feasible to test the simple case for our board. I saw the "echoback" example code, which gives instructions on how to set up Windows terminal but not linux terminal. I wonder what I should do on the linux terminal(imx6) on the other side. The schematic is attached for your reference, and can you give some hints?

The first one is imx6(linux side) and second one is dsp.

Thanks,

Yi

Hi Sal,

Thanks for your reply. I read the manual and saw that 0x08AA is needed for 8-bit boot mode. But I cannot find the exact expected header characters to transmit, it still failed after three characters even if I started transmission with A, A, 8, 0. My purpose is to echoing back a series of characters to verify hardware connection for boot-mode. I wonder if there is anyway to do it successfully more that just 3 characters or not. I really appreciate your help.

Best,

Yi

You need to send 'AA' then '08'.

You can also use the serial flash programmer and hex utility to do this, although it may be overkill for what you are trying to do.

Please see www.ti.com/lit/sprabv4

Also, you can do as Cody suggested and use the sci echoback examples in controlSUITE or C2000Ware www.ti.com/.../c2000ware.

You can use CCS to build and load the sci echoback example onto the device via JTAG.

sal

Sal,

I would like to take the first advice. But based on my program, how can I sent 'AA' then '08' using char array? I tried to do like this:

unsigned char sendData[8] = {'A','A', '0','8', 1,2,3,4}. But it still failed after '0', which is third character. Can you give any detailed guide on how to do this?

Thanks,

Yi

Hi Yi,

The reason for this, is that you are sending ASCII characters and '08AA' must be sent as a hex value.

Please try the sci echoback example or the serial flash programmer.

Regards,
sal

Hi Sal,

Since you have found the problem, can you explain how to do it exactly? I am a little confused about your saying of ASCII and hex value. How should I initialize the array if not as below?
unsigned char sendData[8] = {'A','A', '0','8'} or unsigned char sendData[8] = {'A','A',0,8}

Thanks,
Yi

Sal,

Thanks for your advice and I tried to send it in hex as you said. But even the autobaud failed this time. It seems that only sending 'A' first will lock autobaud and make the following transmission possible. So now I can still only send 3 characters successfully at most. My code is modified based on autobaudLock from f021_DownloadKernel.cpp. Have no idea of what's going on...

Thanks anyway for all!

Yi

Sal,

Finally it works! I send 'A' to lock autobaud, then send the array like sendData[8] = {0xAA, 0X08, 1,2,3} and it does echo back each character successfully. I just tried to send 32 char characters at most, which can help verify our hardware. But just out of curiosity, is there any restriction on how many bytes I can send after "0x08AA"? Is it the whole address location that I can have access to or just part of it?

Thanks again for all your advice and patience!!

Yi

There is a restriction, in some sense. The data stream is expected to be a specific format. Eventual a block size is sent to the SCI bootloader specifying how many bytes to continue to receive in that block. For more information, please see the ROM and Bootloader section of the TRM.

sal

Also, the bootloader is only able to program RAM. It cannot program Flash.

sal

Sal,

I saw the block size definition in manual and will read it carefully later. But I wonder what you mean by "the bootloader is only able to program RAM. It cannot program Flash".Does that mean all characters or information received through bootloader will only stored in RAM not Flash, not like the program downloaded by emulator which can choose to be stored in Flash?

Thanks,
Yi

That is correct. The bootloader is only able to store in RAM. It cannot store to Flash.

That is why we provide the serial flash programmer.

sal

When you say bootloader, it is loaded in the way that I write characters then it echoes back. While for serial flash programmer, there is a way to load it into flash, which I did not take a deep look at. Since my major goal is to test, stored in RAM does not matter. But if we are gonna update firmware of DSP, then serial flash programmer is to be used. I assume that is the difference, right?

That is correct.

You can also search the forum for more details. There are many threads concerning DFU.

sal

Really appreciate all of your help! Will dig in more in the future.

Best,
Yi