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

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

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

Jump to solution
1,094 Views
yo_ku_
Contributor II

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?

Tags (1)
1 Solution
1,010 Views
yo_ku_
Contributor II

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.

View solution in original post

7 Replies
1,079 Views
frank_m
Senior Contributor III

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.

0 Kudos
1,011 Views
yo_ku_
Contributor II

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.

1,003 Views
frank_m
Senior Contributor III

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.

0 Kudos
1,073 Views
yo_ku_
Contributor II

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.

1,065 Views
frank_m
Senior Contributor III

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 ...

0 Kudos
1,062 Views
yo_ku_
Contributor II

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.

0 Kudos
1,053 Views
frank_m
Senior Contributor III

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.

0 Kudos