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.

TMS320C6416T: CCS compiler

Part Number: TMS320C6416T

Hello, I am configuring EDMA interrupt using DSP/BIOS v5.42 on CCS v6.1.3 and I am using DSK6416T DSP. I have designated ISR for HWI_INT8 from the properties as _edmaHwi where edmaHwi() is the name of my C function. I am also writing the received data in a text file (not from DSP/BIOS).

My question is that, although, I get the correct received characters but the file isn't being written when I configure the interrupt using DSP/BIOS. That is, the characters written on the file are blank spaces although the received characters are not blank spaces. 

I am attaching my code for the file writing function. Is there an issue with my code? Although without DSP/BIOS, my written file is not blank spaces. Is there an issue with how I am configuring EDMA_INT8.

void file_write (bool bits_array[],int len)
{
/*Function Input: bits_array*/
FILE *write;
int i,index;
char var;
bool b[8]={0};

write = fopen("C:\test\output.txt", "a+");

for (index=0; index < len ; index++)
{
for (i=0; i<8; i++)
{
b[i] = bits_array [i + (8 * index)]; }
var =bin2deci_bool (b, 8);
fputc(var, write);
}
fputs("\n", write);
fclose(write);
return;}

  • Hello!

    It is not clear where do you run those file writing job. When people speak about DSP and DSP/BIOS, that usually presumes some code is running on the target, and normally there is no operating system capable to handle DOS-like file system. It is possible to upload DSP data to some kind of host computer, which in turn may have access to file system, but that requires considerable amount of work. Could you please explain your setup in more detail?

  • Okay. I understand. Here's my testing scenario:

    There are two PCs . One acts as the transmitter with one DSK6416T dsp while the other acts like a receiver connected with another DSK6416T dsp. Digital data is being transmitted via AIC23 codec through aux cable. 

    The file writing function is at the receiver end and runs on the target CPU ( not DSP/BIOS).  Binary data is being fed to the file writing function which in turn converts it into characters which are then written in the file through "fputc" function. Although the function below outputs the correct character but the "fputc" function is writing blank spaces. 

    var =bin2deci_bool (b, 8);
  • Okay, I assume receiver board is connected by emulator with PC, so you see files get created.

    Here I step on the land I've never been before, so please don't take my suggestion as expert's one.

    You mentioned this happens in EDMA interrupt service routine on a system without DSP/BIOS. Compiler manual tells something about reentrancy and CIO buffer access protection with critical section. In your situation I would first test, whether characters get transferred right way in non-ISR routine. However, I have no recipe if that test fails too.

  • You mentioned this happens in EDMA interrupt service routine on a system without DSP/BIOS. Compiler manual tells something about reentrancy and CIO buffer access protection with critical section.

    Can you please elaborate on this point?

    EDMA_INT is being scheduled by the DSP/BIOS. The file writing is done by the target CPU. 

    Is there a way to get the output and have the file written through DSP/BIOS?

  • Hi,

    DSP/BIOS is a light weighted real-time kernel. It provides real-time scheduling and synchronization, but does not have file I/O capabilities. 

    Any file I/O performed by applications running on the DSP has to go through the JTAG, which is a slow operation and should not be put into an ISR. 

    Regards,

    Jianzhong

  • Hi again,

    I am sorry to not provide reliable recipe, yet again I would suggest to attempt write out of idle loop rather than from ISR.

  • Yes, I have noticed that the file writing operation slows down our process and if combined with a process containing the ISR, data is missed. 

    Any file I/O performed by applications running on the DSP has to go through the JTAG, which is a slow operation and should not be put into an ISR

    Can you suggest an alternative to the file-writing operation? printf on the console is slow too. I have tried LOG_printf through DSP/BIOS but in the trace variable, I get 1 character and not the whole word consisting of for instance 5 characters. 

  • Is it okay to save to memory the characters you receive, and at the end, write all the received characters to a file?

  • I have tried saving the received characters in a buffer and then writing them in a file all at once, but I have encountered sequencing error that is, for instance, if I send characters "HelloworldTest"' , after saving the characters in a buffer and writing them, I get sometimes, "HelloTestworld" or "HelloHelloHello" etc. 

  • Hello!

    At least this test proves characters get printed.

    As to "sequencing issue", do you send your message just once or repeatedly? How do you memorize and update write pointer? What what thread do you perform printing?

  • At least this test proves characters get printed.

    This is for the case without DSP/BIOS. 

    As to "sequencing issue", do you send your message just once or repeatedly? How do you memorize and update write pointer?

    I send my message repeatedly. By default, I think that the writing pointer adjust itself when the file after appending the data close by fclose(write). We are not doing implementing any extra technique to update and memorize the pointer. 

    What what thread do you perform printing?

    Can you elaborate on this point? 

  • I am new to DSP/BIOS and am not familiar with threading. 

  • Well, threading is often required in real life applications. On the other hand, complexity of implementing preemtive threading is so high, that people needing that use some kind of proven RTOS. DSP/BIOS is such an OS from TI.

    When we suggested use buffer, receive characters, and then write we assumed you are using some kind of synchronization, say incoming characters get written to the buffer in incremental fashion. Here we assume you use some kind of pointer, where to write next received character. Once portion of data received, content of the buffer is written to the host. We expect, that no more characters are written to the buffer at this stage.

    As to the last, I thought you are doing this on DSP/BIOS based application, so was asking about thread used for reception and write. This probably irrelevant in no-os case. Still I wonder, do you run any kind of ISR to populate your data on receiver side?

  • Let me explain again my testing scenario:

    Non-DSP/BIOS scenario:

    One acts as the transmitter with one DSK6416T dsp while the other acts like a receiver connected with another DSK6416T dsp. Digital data is being transmitted via AIC23 codec through aux cable

    As I mentioned before frame of data is being transmitted on EDMA transmit event XEVT2. This data is modulated, RRC filtered and shifted to a carrier signal by 1800Hz. The data is being sent continuously. 

    On EDMA receive event REVT2, I receive a frame of data. The received data is processed. My processing time is 7msec approx and my EDMA interrupt arrival time is 16msec. So, I think, before the arrival of the next frame, my previous frame is processed. The issue at hand is that, sometimes, I receive correct frames and sometimes my received data is corrupted and out of sequence. 

    When we suggested use buffer, receive characters, and then write we assumed you are using some kind of synchronization, say incoming characters get written to the buffer in incremental fashion. Here we assume you use some kind of pointer, where to write next received character.

    In the file writing function, the

    write = fopen("C:\test\output.txt", "a+"); 

    a+  opens the file for reading and appending (writing at end of file). The file is created if it does not exist. The initial file position for reading is at the beginning of the file, but output is always appended to the end of the file. So, we assume that once the next frame is received, the data is appended always at the end of the file. I have tested that in loopback scenario. 

    DSP/BIOS scenario:

    The rest of the process is the same as the non-DSP/BIOS scenario, the only difference being that only EDMA interrupt is being scheduled by the DSP/BIOS scheduling that edmaHWI function is defined in the HWI_INT8. 

  • Hi again,

    The longer we discuss your situation, the more it turns your issue is neither with compiler, nor with BIOS. Please understand, file i/o is slow process, and it is even more slowed down due to the fact it gets performed over JTAG of your emulator. I bet your hope 9 ms is enough for that is prohibitively optimistic. I would rather think that file i/o is just inappropriate for such periodic realtime load. What we suggest here is attempt kind of synchronized, one time operation. Say, receive frame of data and disable all further RX events, process you data, write to disk, and only after that re-enable reception of next frame of data. If that would work, you'd know your issue lays in scheduling.

  • Say, receive frame of data and disable all further RX events, process you data, write to disk, and only after that re-enable reception of next frame of data. If that would work, you'd know your issue lays in scheduling.

    That would suggest we disable the REVT2 that is we disable the EDMA interrupt. Also, how can the receiver receive event sync with the transmitter transmit event? If the transmitter sends frame at every transmit event/interrupt and if I disable the receive event at that instant, then wouldn't we lose the data? 

  • Hello!

    At this point it is unclear what is the reason of data corruption. What I suggest is an attempt to narrow search area. Your system is running continuously. It happens pretty often that data get corrupted if were not processed in time. Thus I suggest you disable receiver activity until whole chunk of data gets dumped to PC. If this test passes, but continuous run leads to data corruption, most likely you have a scheduling issue.

  • Hello,

    Both the transmitted and received data are visualised on oscilloscope . When we visualise the data, both are the same, there is no delay shown on the oscilloscope. However, when we save the processed data in a buffer at the Rx side and then pass it through the file writing module then data is corrupted.

  • Hello!

    It is very likely corruption happens due to scheduling issue during write process, which in turn is slow one. However, there might be number of other reasons for the trouble you observe. Your observation with the scope is not relevant, it just tells DSP side is okay. Still there is write access to host PC file system, which is slow itself and even more slowed down because it is performed over JTAG. I am gently pushing you to try one time writing to eliminate real time scheduling out of equation because in your situation I would be doing that way. Perhaps community may suggest other recipes.

  • Thanks rrlagic for sharing your insight into this.