Calypso errata10542 reproduce

[JayceYang]

Hi Expert,

Customer LEAR asking for a method to reproduce this Calypso ERRATA10542 issue, for testing whether the workaround works.

Could you help how to reproduce it?

[lukaszadrapa]

Hi @JayceYang 

for example, it should be enough to read the POPR more times on one DMA request while only one received frame is present in the FIFO. That means - in master mode, send one frame out, so one frame is received. Configure the DMA to read the POPR two times on one request - set NBYTES to 2 and SSIZE to 8bit (case for 8bit frame). This will generate two reads, so it follows this sentence:

"If the DMA is configured to transfer more than 1 FIFO location size of data, the FIFO Fill Flags may not be properly cleared indicating that the FIFO is not full even when the FIFO is actually full (for Transmit and Command FIFO) and not empty when the FIFO is actually empty (for Receive FIFO)."

Regards,

Lukas

[jalilin]

Hi,

The FIFO Fill Flags mentioned refers to the DSPI Status Register(SR[TFFF/RFDF/CMDFFF]) ?

What is the expected value when the FIFO is full?... expected value when the FIFO is empty?...

I tried checking the DSPI register by viewing it in the Trace32 window… but Trace32 crashed…

it seemed that Trace32 is prevented from reading it… how can we check the FIFO Fill Flags/Status register in our part?...

Also, if you can provide a more detailed step-by-step checking instruction from your part would be

mostly appreciated. Or if you have sample code that we can use to check this then that would be

most helpful also.

[lukaszadrapa]

Short update - I did quick test on my board but I was not able to reproduce it. I need to allocate more time to check which scenario triggers this exactly.

Regards,

Lukas

[jalilin]

Hello Lukas;

Maybe you can show a screenshot sample of the register values when the issue occurs?... and then show the values when the issue does not occur?... Please use a Tx direction in the sample... we need to know from our part what to check here. Please indicate also the procedure to reproduce...

Thanks.

-jalilin

[lukaszadrapa]

Hi @jalilin 

here is what I can see on my side:
I reused code from AN4830, example spi_dma:
https://www.nxp.com/docs/en/application-note/AN4830.pdf
https://www.nxp.com/webapp/Download?colCode=AN4830SW&appType=license&docLang=en

First, I tested the transmission when DMA is configured as expected - that means size of transfer is set to 2 (one 32b word is transferred at a time) for both source and destination, NBYTES is set to 4 (only one word is transferred on one DMA request) and CITER-BITER is set to 8 (eight frames are sent). I'm sending values 0-7 in the SPI frames. See screenshots with "correct__" prefix.

Then I modified the DMA settings - I changed NBYTES to 8 (that means two words are transferred to the PUSHR register on one DMA request) and I changed CITER-BITER to 4, so still eigth frames should be sent (in case this configuration works). See the screenshots with "bad__" prefix. Two frames are missing in this case. I can't see that the flags got somehow stuck as expected earlier, I can see only missing frames.

To ensure that the DMA is configured as expected (considering Extended SPI Mode is disabled): SSIZE and DSIZE must be always 2 (4 bytes per tranfer) and NBYTES must be 4 (one word transferred on one DMA request coming from SPI). CITER and BITER that say how many frames will be sent. This will always work.

In extended mode TX FIFO and CMD FIFO can be written independently using 16bit access but my understanding is that you don't use this mode.

Regards,
Lukas

[jalilin]

Hello Lukas;

we check our config as compared to your config(Good and Bad) and seems the CITER-BITER is separated from our Trace32 setup... can you help us check the equivalent combined value of the two? so that we can make a direct comparison with the settings from your Good/Bad checking?...

we also observed strange behaviour in TFFF and TXNXPTR, See Remarks below... are these behaviours normal?...

we dont have access to a development board so, we make a customized checking using our actual product...

.customize checking.
Step_1: Load the software in the module, reset, and run.
Step_2: Check the DMA(TCD1) config
Step_3: Operate/ increase the communication traffic between the PLC and OBC/MCU and check the status registers.

Result:

.DMA Config.

                SSIZE = 2, DSIZE = 2, NBYTES = 4, CITER = 1, BITER = 1

.DSPI status register.
                TFUF = 0
                TFFF = 1 <- sometimes change momentarily then goes back to value 1.
                TXCTR = 0
                TXNXTPTR = 2 <- sometimes change to 0 or 1 or 3 

BR.

-jalilin

[lukaszadrapa]

Hi @jalilin 

I'm not sure if I can understand the first part of your post. CITER and BITER values say how many frames will be transmitted. So, it's application dependent. There can be any value. Everything depends on your application.

.DMA Config.

SSIZE = 2, DSIZE = 2, NBYTES = 4, CITER = 1, BITER = 1

- this is correct. SIZE and NBYTES are configured as expected. CITER and BITER are configured to send one frame only.

If you are watching the TFUF, TFFF, TXCTR and TXNXTPTR in realtime, yes, you should see something like this. It means the the SPI+DMA are working, the FIFO is being filled and data are transmitted out. I can see no problem here.

Regards,
Lukas

PS. I will be on vacation till 2nd January. If anything else is needed, the best way is to create new thread or new case for my colleagues.

[jalilin]

Hello Lukas;

Thanks for the support, we have concluded this checking and we think we are not affected due to the difference in the register values... and also, not reproduce during actual check in the setup.

Regards,

-jalilin

[jalilin]

Hello Lukas;

Ok, thanks... this is a big help to our checking... 

BR.

-jalilin

[jalilin]

Hello Lukas;

Ok, no problem... were busy with other task ourselves here so were not able to continue to checking for this one for the moment... Anyways, i replace our board here the last time and the reset did not happen anymore... i was able to manually check the DSPI using the Trace32 windows... fyi.

-jalilin

[lukaszadrapa]

Hi @jalilin 
Yes, those are the flags. The description is not very clear but I expect the flags should show the opposite - depending if it is receive or transmit buffer.
No, Trace32 does not prevent the access to DSPI registers. I can see only two options here - the DSPI module is either not enabled in Mode Entry module, so the DSPI is turned off and its registers are not available in the memory map or the memory protection unit is configured to restrict the access from debugger.
But in any case, the Trace32 should not crash, it should just shows '??' marks as usual - when an access from debugger is terminated by bus error.
I will try to find some time to check it on my side.
Regards,
Lukas