fsi_ex3_loopback_dmacontrol doubts about this FSI code

Hi Pedro,

Please expect a response for this query tomorrow.

Best Regards,

Delaney

Good morning Delaney,

Thank you very much for taking your time to reply to me, I appreciate it very much. It was very clear to me the answer you gave me. Basically the first address of GS0 is reserved to keep the count of DMA transfers and since since it is continuous when it reaches "*(uint16_t *)GS0_START_ADDR = (uint16_t )countDMAtransfers;" it has already triggered the transfer without this change and therefore the first address cannot be compared. I think this is how you explained it to me.
Thank you very much for the good answer Delaney, have a nice day.

Best regards,
Pedro.

Hi Delaney, I wanted to ask you another question. Do you know if the field for the number of words sent by FSI can be changed at any time? I mean, if I want to change nWords in different points of the program with the line "FSI_setTxSoftwareFrameSize(FSITXA_BASE, nWords);" without having to perform a Reset in the FSI. I would like to develop a program for Master and Slave in which the Master and Slave would have the possibility to send 1, 2 and 16 frames depending on the content of the frame received from the Master/Slave without having to reset the peripheral, with DMA in TX and RX in both Master&Slave. 

BR,

Pedro

Hi Pedro,

I don't see anything in the TRM mentioning this so I would have to test it out.

This set up may be difficult to do using the DMA however since the varying frame lengths would need to be accounted for in the DMA settings. Would the change in frame length always happen in the same order (ex. 1, 2, 16, 1, 2, 16, 1...)? The calling of FSI_setTxSoftwareFrameSize() and FSI_setRxSoftwareFrameSize(); would also have to be done by the CPU which runs independent of the DMA. The only way to synchronize this function call with the DMA would be to do it in a DMA interrupt, which means at the very least each full transfer would have to use the same frame length.

Best Regards,

Delaney

Okey, thank you Delaney. I will investigate about it. 

I have another question Delaney, how in the loopback execises like this with DMA or ex1 with CPU, does the PING frame is sent automatically?

In the exercise of STAR of daisy_nose, the ping frames are sent as following:

FSI_setTxFrameTag(FSITXA_BASE, FSI_FRAME_TAG0); 
FSI_setTxFrameType(FSITXA_BASE, FSI_FRAME_TYPE_PING);
FSI_startTxTransmit(FSITXA_BASE);

I have seen in the oscilloscope when I debug loopback exercises that sometimes in the screen appears PING frames but I don't know in which part of the code it's implemented this (maybe when you set the reference value of timer and watchdog????)

Thank you very much for your help.

BR,

Pedro

Thank you very much Delaney, I have read this part of the TRM and it's how you said in your reply

I appreciate how you helped me. Have a nice week.

BR,

Pedro

Good morning Delaney,

I wanted to ask you one more question. In the fsi_ex3_loopback_dmacontrol, all the loopback is done with DMA. My question is about the trigger of the DMA. As the ping frames are sent periodically with the counter from the TX, when the RX receives this frames does it triggers the DMA although it is not a data frame?? I don't see in the code where it's configured it so I guess that when the RX receives a DAT frame or PING frame, it triggers the DMA and it saves in RAM the data from the RX_BUF_BASE, bit it should be only with data frames.

Another question I have related with the DMA control of FSI is the following:

I want the slave when it receives a DATA frame from the Master, to have a DMA channel that:
- First, check the TAG of the frame that has arrived.
- Second, if the TAG is correct, that the DMA is in charge of sending the Words of the RX_BUF to the GS memory address that I have chosen. If it does not match, discard the message and do not store it in memory.
I thought of doing it with 2 DMA channels as they do the communication in some example, one for the UDATA_TAG and one for DATAFRAME. The problem is that both have the trigger when the RX_FRAME event arrives so the DATAFRAME channel would put in memory the frame data even if the tag is not correct. I would like to know how to coordinate both DMA to avoid this problem.

I will wait for your answer. Have a nice day,

BR,

Pedro.

Hi Pedro,

I will look into this and get back to you tomorrow.

Best Regards,

Delaney

Good morning Delaney,

As I told you, I am looking at FSI possibilities for a Master-Slave application I want to implement. I want to realize a star architecture (not daisy-chain) at first with 4-5 slaves.
I have seen the Star Broadcast example 9 "fsi_ex9_star_broadcast.c" but there is one thing I want to implement:
- I want to eliminate waiting in while loops of the Slaves reception. Para ello, he pensado en realizar interrupciones por FSI y DMA (interrupciones DMA que sean disparadas en las interrupciones FSI).
- I want the messages I send by Tx to go with a TAGx (x=1 to 5) and receive response only from the Slave TAGx. So I want to make a communication with a single slave at any time and each of the slaves respond to the message from the master if they match the tag assigned to each of them fixed. 

In the example fsi_ex3_loopback_dmacontrol.c dedicates 2 DMA channels for each RX channel. For me this would be impossible because CPU1 has 6 DMA channels and if I want 5 slaves, I should dedicate only 1 DMA channel for each TX or RX in the Master. In the slave, since it only receives FSI communication from the master I could implement 2 DMA channels per TX or RX. However, I wanted to program the Master and the Slave with the same criteria, therefore, I want the slave to have only one DMA channel per RX or TX.

I will tell you how I have it implemented in the Slave:

•  I configure the Tx to trigger when writing to UDATA-TAG register (or force it with starttx) with:

FSI_setTxStartMode(FSITXA_BASE, FSI_TX_START_FRAME_CTRL_OR_UDATA_TAG);

• I configure Rx in such a way that I allow RxA interrupts with the following lines, so the INTERRUPTION appears when the RX receives a FSI frame with TAG=txDataFrameTag (pls confirm me if this works as I think)

FSI_setRxFrameTagRef(FSIRXA_BASE, txDataFrameTag);
FSI_setRxFrameTagMask(FSIRXA_BASE, 0000);
Interrupt_register(INT_FSIRXA1, &fsiRxInt1ISR_DATAFRAMES); //interrupciones de FSI RX INT1 para el handshake
Interrupt_enable(INT_FSIRXA1);
FSI_enableRxInterrupt(FSIRXA_BASE, FSI_INT1, FSI_RX_EVT_DATA_FRAME_TAG_MATCH);

• I configure the DMA channels and I start the DMA channels with the following code. The most important is the config dma functions where I choose to trigger the DMA with SOFTWARE. In case you want to know, the DMA_TRANSFER_SIZE_IN_BURSTS is 1 and nWords is 16. So the purpose is to receive 16 words of data from FSI and store it in the first 16 directions of GS2 (the same in Tx but taking the first 16 directions from GS0 to transmit it throught the TX buffer). 

fsirx_dma_config();
fsitx_dma_config();
FSI_enableRxDMAEvent(FSIRXA_BASE); //FUNCION DE FSI PARA QUE DEJE QUE DMA ACCEDA A SUS DATOS
FSI_enableTxDMAEvent(FSITXA_BASE);
DMA_startChannel(DMA_CH1_BASE);
DMA_startChannel(DMA_CH2_BASE);
//IN "fsitx_dma_config()" I CONFIGURE THE FOLLOWING
void fsitx_dma_config() //COPIADA DE EX3 LOOPBACK. CONFIGURAR BIEN
{
    //
    // CANAL 1 PARA DATA-FRAME (DISPARADO POR SW, EN ESTE CASO POR CANAL 2 DMA RXTAG)
    //
    DMA_configAddresses(DMA_CH1_BASE, txBufAddr, (uint16_t *)GS0_START_ADDR); //A DIFERENCIA DE RX AQUÍ SE CAMBIA DIRECCION DESTINO Y DIRECCION SRC
    DMA_configBurst(DMA_CH1_BASE, nWords, 1, 1);
    DMA_configTransfer(DMA_CH1_BASE, DMA_TRANSFER_SIZE_IN_BURSTS, 0, 0);
    DMA_configWrap(DMA_CH1_BASE, DMA_TRANSFER_SIZE_IN_BURSTS, 0, nWords, 0);//CAMBIO DE FUENTE Y DESTINO
    DMA_configMode(DMA_CH1_BASE, DMA_TRIGGER_SOFTWARE, DMA_CFG_ONESHOT_DISABLE|
                   DMA_CFG_CONTINUOUS_ENABLE | DMA_CFG_SIZE_16BIT); //IGUAL QUE EN RX PERO CAMBIO EN EL Nº TRIGGER DEL DMA
    DMA_setInterruptMode(DMA_CH1_BASE, DMA_INT_AT_END);
    DMA_enableInterrupt(DMA_CH1_BASE);
    DMA_enableTrigger(DMA_CH1_BASE);

}
//IN "fsirx_dma_config()" I CONFIGURE THE FOLLOWING
void fsirx_dma_config()
{
    //
    // CANAL 3 DMA PARA DATA (DISPARADO POR SW, EN ESTE CASO POR CANAL 2 DMA RXTAG)
    //
    DMA_configAddresses(DMA_CH2_BASE, (uint16_t *)GS2_START_ADDR, rxBufAddr); //copia el contenido del buffer rx en GS2
    DMA_configBurst(DMA_CH2_BASE, nWords, 1, 1);
    DMA_configTransfer(DMA_CH2_BASE, DMA_TRANSFER_SIZE_IN_BURSTS, 0, 0);
    DMA_configWrap(DMA_CH2_BASE, DMA_TRANSFER_SIZE_IN_BURSTS, 0,
                   DMA_TRANSFER_SIZE_IN_BURSTS, 0);

    DMA_configMode(DMA_CH2_BASE, DMA_TRIGGER_SOFTWARE, DMA_CFG_ONESHOT_DISABLE|
                   DMA_CFG_CONTINUOUS_ENABLE|DMA_CFG_SIZE_16BIT);
    //DMA_setInterruptMode(DMA_CH2_BASE, DMA_INT_AT_END);
    DMA_disableInterrupt(DMA_CH2_BASE);
    DMA_enableTrigger(DMA_CH2_BASE);
}

Therefore the idea is as follows in the Slave:
- RX FSI interrupt because it has received a data frame with a TAG corresponding to that Slave.
- In the ISR the received TAG is stored in position 17 of GS2 and performs a FORCE TRIGGER of the RX DMA channel that writes the 16 dataframes in GS2 from position 1 to 16 and of the TX DMA channel that writes the 16 dataframes from GS0 to position 1 to 16 of TX BUFFER. After finishing this a TX DMA interrupt appears that the only important thing it does in its ISR is to write the GS0 TAG position 17 to the UDATA-TAG register of the FSI that as I have put in the line "FSI_setTxStartMode(FSITXA_BASE, FSI_TX_START_FRAME_CTRL_OR_UDATA_TAG);" causes the TX FSI transmission to be triggered.

I would like to know your opinion about this architecture, if you see any problem in using FSI with DMA in this different way. I also make in the middle of the code a change in the ISR of RX because for the handshake I configured these lines,

Interrupt_register(INT_FSIRXA1, &fsiRxInt1ISR_HANDSHAKE); //interrupciones de FSI RX INT1 para el handshake
Interrupt_enable(INT_FSIRXA1);

but then for the normal operation of the master-slave communication I change the ISR:

Interrupt_register(INT_FSIRXA1, &fsiRxInt1ISR_DATAFRAMES); //interrupciones de FSI RX INT1 para el handshake
    Interrupt_enable(INT_FSIRXA1);

I also clarify that the fact of using the RX DMA by SOFTWARE TRIGGER is because I think that if I put it as DMA_TRIGGER_FSIRXA, I understand that the DMA would be activated when it receives a frame by FSI, even if it is from a different TAG than the slave. While if I activate it by SOFTWARE in the ISR of the RX I make sure that it will implement the DMA only when the TAG of the slave arrives, which is the one through which the interrupt appears by the line "FSI_enableRxInterrupt(FSIRXA_BASE, FSI_INT1, FSI_RX_EVT_DATA_FRAME_TAG_MATCH);". 

I expect you could help me with this plan. If you think that it could be implemented in a more optimal way, please say to me. 

Have a nice week Delaney.

Best regards,

Pedro

Good morning Delaney,

Thank you very much for your answer :). I think you got well what I am doing and I really appreciate your reply, it has been very useful.

I have some questions about some things you said:

1st: Normally I would suggest using user data matching instead for the slaves, since in this case the frames themselves wouldn't be placed in the FSI RX buffer unless the UDATA matches. This would mean the regular FSIRX DMA trigger could be used and would only transfer valid data on the RX line for each slave. However, you are using the F2838x correct? Unfortunately, UDATA matching is only available on devices F28003x and F28P65x as this feature was added into the Type 2 design of the FSI peripheral. If you wanted to switch to one of these devices, the implementation could be simplified significantly. Just putting that option out there. Assuming you want to use tag matching though, the following are my notes about your planned implementation.

I dont understand very well the development use of the user_data, for me it's like another field as the tag in a message from FSI. I planned to use the TAG in order to make an order that the slaves store information from master and send their slave information to master. Nevertheless, the TAG and the USER-DATA comes from the same register and they use the same interruption "FSI_RX_EVT_DATA_FRAME_TAG_MATCH". But as you said this implementation only can be done with F28003x and F28P65x. Unfortunately, I am able only to develop this in TMS320F28388D because is the uP that we are going to develop the project. But I get that feedback as an important reason in order to select the proper microprocessor. 

2nd: Is there a reason why the received tag needs to be stored in memory? The tag matching scheme looks good. For the handshake mechanism, these would be triggered on the same interrupt flag condition, correct? If this is the case, I would recommend keeping them in the same ISR and using a global variable to keep track of which operation the slave is currently doing.

No, there is not a reson for that, sincerely. If the TAG matches in the FSI INT and then it triggers the RX DMA to store the info, the important data is the nWords transmitted in the dataframe. About the handshake mechanism, I used different ISR for RX handshake and RX normal frames and I changed the ISR aftr the handshake. However, I am going to take your advice to use the same ISR and use a global variable flag to differentiate between Handshake reception and normal transmission reception, thus saving me an ISR and various problems that may arise. 

3rd: I would suggest using one DMA channel for transmitting (that would be connected to all slave RX lines) and five channels for receiving from each slave device. You could set up the master receive DMA's the same as the slave receiver DMA's using the tag matching interrupt and a software DMA trigger. For the one transmit DMA, I would suggest adding an end of transmission DMA interrupt that inside its ISR will write to the UDATA and TAG register and initiate the master transmission. This way the DMA will first transfer the TX data to the FSI TX buffer, then the UDATA and TAG will be written after its finished and send the frame.

Yes, that's what I had in mind, to use one DMA channel for TXA and one DMA channel for each RX receiver. As there are 6 DMA channels per CPU, I had in mind 1 for TXA and 1 for RXA, 1 for RXB, etc.... I have not yet done the master code completely but I have an idea of how to do it. I will also evaluate later if I will use CPU2 for the 3 remaining RX channels (RXF, RXG, RXH) to use it with DMA and so I can expand the number of slaves up to 8. But first I want to develop it on CPU1 for 5 slaves max. Regarding the use that would be made of the channels, what you tell me is very similar to how I have it implemented in the slave so it seems that there is not much complication, between today and tomorrow I will try to implement it well and if I fall into any problem I will consult you, thank you very much Delaney. 

4th: Using the continuous mode of the DMAs in this case shouldn't be an issue since you are using software triggering. Keep in mind that if you use the FSI triggers for any DMA channels, continuous mode could cause some issues like we saw had to be accounted for in the example. If you end up using the FSI triggers for any DMA channels, I would instead disable continuous mode and use the end of transfer interrupts to reenable the DMA channel for further transfers.

My intention is to use the DMA as in the slave with Software Trigger to first ensure that the TAG received is the right one, but I will let you know as I develop the code. Regarding DMA's OneShot mode, it is my understanding that it only fires one burst. The truth is that my idea is to use only one burst of 16 words, so in principle I am indifferent to use OneShot and Continuous mode because as I only transmit 1 burst of 16 words... How do you see this?

Thank you very much for taking your time and answering everything perfectly. Have a nice day Delaney.

Best regards,
Pedro

Good morning Delaney,

Thank you very much for your help. I will let you know if I have any difficulties or any aspect of the FSI that I am not clear with the documentation. Have a good week.

Best regards,
Pedro