S32K ISELED buffer override

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K ISELED buffer override

Jump to solution
1,473 Views
christianmächle
Contributor II

Hello,

I am using the S32K144 with the ISELED driver (S32K1_ISELED_RTM_4.0.0) and have trouble receiving upstream data.

If I only send downstream data (digLED_Set_RGB) to the ISELEDs, everything works fine.

However when I also send an upstream command (digLED_Read_Temp), at some point the ISELED driver will override

my the reception buffer digLEDResultBufferStrip and the memory after that with zeros (basically the buffer then contains the (more or less expected) responses of all LEDs and then zeros afterwards in the unused buffer space, which i filled with dummy values beforehand and more zeros in the memory locations after that).

The ISELED UserGuide states that the ISELED reception buffer should be double in size as the number of LEDs used, but even if I use five times the size, the driver will override the buffer and the memory after that.

The override mostly seems to have happened when the callback function returns with CRC_ERROR or sometimes RECEPTION_TIMEOUT.

Does anyone else experienced or solved this problem before and can help me?

Tags (1)
1 Solution
1,380 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hello Christian,

Sorry for the delayed response.

I'm posting what I received from our ISELED SW team.

"The driver calculates the number of LEDs in the chain using the response from the last LED in the chain (its address) and sets the DMA for reception accordingly. If the response is corrupted (crc error) this calculation cannot be used.
The chainlength parameter from the digLED_ReadDataResultType type is an input/output parameter. You can set this parameter to limit the amount of responses that will be received after a read command. For example, if the buffer is 74 words (37 LEDs) than before calling a read function the chainlength parameter should be set to 37. After the function completes, the chainlength parameter will contain the amount of LEDs found in the chain. If the last reception was corrupted, then this parameter will have an unpredictable value. By checking this parameter, and making sure that it is set to a value lower than the receive buffer may accommodate, the overflow can be avoided."

I hope it helps,

BR, Daniel

View solution in original post

0 Kudos
4 Replies
1,380 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hello Christian,

The ISELED driver requires a buffer double in size than the number of LEDs because the raw data received by the LEDs occupies 2 32bit words per LED. However, the decoded data only occupies 1 32bit word per LED. The buffer passed in by the user is also used for raw data reception. After the raw data is received, the driver then decodes the messages and places them in the same buffer. Once this is done, the first half of the buffer is filled with decoded useful data, and the second half is filled with garbage (no decoded data). Once the  decoding is complete, the driver deletes the garbage data as it has no use. So this is why you see the 0s in the buffer.

BR, Daniel

0 Kudos
1,380 Views
christianmächle
Contributor II

Hi Daniel,

thanks for the information. We use 37 LEDs in the string and a buffer size of 1024 32bit values. Just as a test we initialized the whole buffer with a random value. After initialization and if we use downstream commands, the buffer is as we would expect. This means the first 74 values are 0 or valid response data and the rest of the buffer still has the random init value with that it was initialized. Just as you described.

Now, if we include an upstream command in our communication schedule, at some random point during the runtime, the ISELED driver overrides more than the expected 74 values and our buffer now contains more than 74 zeros. Sometimes the buffer size is enough and we end up a couple of the random values still at the end of the buffer but mostly the whole buffer (all 1024 values) are now zero.

Since this happens mostly after the callback returns with CRC_ERROR, could it be possible that when the received data is corrupted somehow the ISELED driver cannot reproduce the number of received bytes correctly and overrides more than the expected memory?

0 Kudos
1,381 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hello Christian,

Sorry for the delayed response.

I'm posting what I received from our ISELED SW team.

"The driver calculates the number of LEDs in the chain using the response from the last LED in the chain (its address) and sets the DMA for reception accordingly. If the response is corrupted (crc error) this calculation cannot be used.
The chainlength parameter from the digLED_ReadDataResultType type is an input/output parameter. You can set this parameter to limit the amount of responses that will be received after a read command. For example, if the buffer is 74 words (37 LEDs) than before calling a read function the chainlength parameter should be set to 37. After the function completes, the chainlength parameter will contain the amount of LEDs found in the chain. If the last reception was corrupted, then this parameter will have an unpredictable value. By checking this parameter, and making sure that it is set to a value lower than the receive buffer may accommodate, the overflow can be avoided."

I hope it helps,

BR, Daniel

0 Kudos
1,380 Views
christianmächle
Contributor II

Hello Daniel,

thank you for your help! We did not know that the chainlength parameter gets overwritten and set it only during initialization. I guess what happened was that the first CRC failure changed the chainlength and on a second CRC failure the driver would use this changed parameter and override more bytes than we reserved in the buffer. We now set this parameter on every new read request and don't experience this problem anymore.