USB-SD/MMC msc does not work due to compiler optimization.

[yo_ku_]

We have EMMC-msc project with target MCU:LPC54S018M MCUXpressoIDE: v11.3.0 SDK:v2.9.0 . It needs the compiler's Optimize Option -O2 for memory footprint and processing speed. But, when I compile it with -O2, this project cannot working. This problem is reproduced by the following NXP sample project.

target board: LPCXpresso54S018M

SDK example:lpcxpresso54s018m_dev_msc_disk_bm (usb example)

Setting: Optimize for more (-O2)

Use SD Card

Could you help us?

[frank_m]

This is most probably a bug on your side. Often, a required "volatile" attribute for variables is omitted, and the compiler intransigently optimizes it out.

E.g. almost everything an interrupt handler touches must be declared volatile, because no static analysis can show the compiler how and when such handlers touch a variable.

You can try debugging and check for routines to return errors, to narrow the code locations down. Debugging highly optimized code can be confusing, though.

[yo_ku_ · Accepted solution]

Thanks frank !
I have debugged carefully based on your advice.
It seems that the following code in main() has been erased by optimization.

*((uint32_t *)(USBFSH_BASE + 0x5C)) |= USBFSH_PORTMODE_DEV_ENABLE_MASK;

I rewrote the code below and it worked.

USBFSH->PORTMODE |= USBFSH_PORTMODE_DEV_ENABLE_MASK;

It was very hard to debug because of the large scope, but I was able to narrow down the problem thanks to the following code I found in the source of startup.

#pragma GCC push_options
#pragma GCC optimize ("Og")
.
.
.
#pragma GCC pop_options

B.R.

[frank_m]

BTW, an easier approach would be to incrementally either exclude or include one source file to optimisation. In other words, you can override compilation setting for individual sources. If the behavior changes, the is a problem in the module.

[yo_ku_]

Thanks for the reply.

This problem is reproduced even with the default NXP sample without my additional code. Therefore, I believe that the omission of the "volatile" attribute you noted may be present in the HAL driver or SDMMC middleware.

B.R.

[frank_m]

Which is not really surprising, at least to me.

Free SDKs hardly ever claim commercial fitness, and the examples are polished to a point were the function well, and demonstrate a capability of the MCU/board. You cannot expect a rigorous test like e.g. required for a safety certificate (which is what am I required to do in my dayjob).

If that helps, some competitor's examples and SDKs are considerably worse ...

[yo_ku_]

Yes, I agree with you.
NXP's IDEs and SDKs, even the free ones, are as good as the paid ones.
Still, I understand that it is not perfect, and I understand that it is getting better every day.
So my concern is that I can get help from the community.

[frank_m]

To a limited extend, yes. You are the one having the target hardware, and the source code. And many contributors here are volunteers with their own day jobs, not directly associated with NXP.

I hope you don't do busy-wait loops. But any delays or strictly timed sequences would be candidates as well.

I would start debuggung, and check what fails. E.g. do the USB / filesystem init functions work ? Or the access functions ?

If not, get down to the lower level driver function(s) raising the error.

This is usually as close as you can get with this method.