MCU-PLUS-SDK-AM243X: MCSPI_fifoWrite produces abort in release-builds with -Oz option because of unaligned access for arm-ldm command

Hello Felix,

Thank you for your query.

Felix Heil said:

here the generated arm-ldm command was the problem, which was generated when using -Oz

Can you please point out the steps as to how you set -Oz?

With default settings, in release build for my setup with TI EVM there seems to be no problem.

Regards,

Vaibhav

Hey Vibhav,

sorry for missing out some information.

So we are not using the evm, nor the examples. I can not see from where it directly pops up, since this issue is in the continue-interrupt of the mcspi-driver. But It could be probably that we have an uint8_t array which is placed unaligned or smth, which produces this problem. Anyway I see this issue in the driver since a cast from uint8_t* to uint32_t* is pretty dangerous all the time and not memory-safe and just shouldn't be done. Especially if the generated ldm-command with the -Oz-option cannot use unaligned access even if the R5F itself supports it.

The -Oz is automatically added as an option when you compile the drivers-sdk-library. So we just use the make-files of the SDK.

regards

Felix

Hello Felix,

I will look through this casting implementation in the drivers and raise an internal JIRA for the same.

Regards,

Vaibhav

Hello Felix,

I have already conveyed this to one of the members from the development team.

Once, I hear back from them, I will update here as well.

Thanks for your patience.

Regards,

Vaibhav

Hello Felix,

These are the comments from the dev team: 

"No, because from application we will be defining buffer size to be uint8_t, uint16_t or uint32_t and accordingly MCSPI_fifoRead8,  MCSPI_fifoRead16, MCSPI_fifoRead32 will be called. SO memory alignment will not come into picture "

Regards,

Vaibhav

Hey Vaibhav. I see what the devs meant, but that wasn't my point. I mean yes, the bufferSize is defined and it call's the correct fifo-function that's fine. But it's reading from a buffer and this buffer is not aligned in my case. which means it's an unaligned uint8_t-address which gets casted to that uin32_t*. This has nothing to do with the bufferSize, it's an alignment issue.

Regards

Felix

Hi Felix,

The expert is currently out of office for a week. Responses to this thread will be delayed.

Thanks for your patience.

Regards,

Tushar

Hello Felix, 

Please expect responses in sometime.

UPDATE: Due to other threads, I will be able to get back to this thread by the end of this week.

Regards,

Vaibhav

Hello Felix,

Please expect responses on this by 27th September. The concerned dev will be available to talk with me on this issue and I can get your questions answered by tomorrow itself.

Latest conversation from the mail:

"

This question is not about the size of the buffer but rather the buffer address.

"

Thank you very much for your patience.

Regards,

Vaibhav

Hello Felix,

Thank you very much for your patience.

Our dev is out of office today, he will be back on Monday. 

Can you please confirm if the following question is your ask?

Felix Heil said:

I mean yes, the bufferSize is defined and it call's the correct fifo-function that's fine. But it's reading from a buffer and this buffer is not aligned in my case. which means it's an unaligned uint8_t-address which gets casted to that uin32_t*. This has nothing to do with the bufferSize, it's an alignment issue.

Do you want to add any thing else to this question?

Regards,

Vaibhav

Hey Vaibhav,

thanks for the reply.
And Yes, that's a bit more details for my problem written down. Just wanted to point out that it's not about the buffer in general but about its address where it's located. So in the end where the fifo-write-functions start reading from.

Regards

Felix

Hello Felix,

Felix Heil said:

Just wanted to point out that it's not about the buffer in general but about its address where it's located. So in the end where the fifo-write-functions start reading from.

Thanks for the additional notes on this.

I really appreciate your patience. Allow me time until Monday evening IST to get back on this thread with updates from the dev team.

Regards,

Vaibhav

Hello Felix,

I have discussed this and raised a software and MCU PLUS SDK bug on this and we are looking forward to hearing suggestions and improvements from the Software Team on this by 3rd October, 2024. Post this I will convey our action plan on this. 

Thank you for identifying this bug and your patience as well.

Regards,

Vaibhav