USB and newlib

[MattT]

Hi,

want to use newlib on my LPC55S69, but the USBHS driver runs into a hardfault. If i use newlibnano, everything works fine.

I started a fresh project to investigate and this problem shows up, even if just the example runs.

I also require the newlib, because i have to port existing code to this MCU, and I dont want to rewrite everything.

Is there a way to get the USB driver run with newlib?

br

[ZhangJennie]

By testing "dev_cdc_vcom_bm", also no error.

see attached.

[MattT]

In your video, you dont use newlib. You are selection newlibnano. On my system is also no compile error. The problem appears, after a PC gets attached to the USB port.

My steps:

1. Compile with newlib (doesnt care if none, nohost or semihost is selected)

2. Load the firmware with my debugger

3. Start application

4. Attach usb to the board

Result: Driver runs in the exception.

When I use newlibnano, everything works fine and the board works like it should.

[ZhangJennie]

Hi

We have reproduced this issue. When using NewLib library, hardfault occurs when calling memcpy and copy length is odd number. If using default RedLib or NewLibNano, there is no this issue.
For the bad case using NewLib, the real root cause is that USB ram can not support unaligned access. When using Newlib, memcpy will copy data byte by byte, which causes the hardfault. However, for RedLib or NewlibNano, memcpy may copy data by a aligned length (based on its algorithm).
Therefore, it is not a SDK issue, this is the limitation of USB RAM.

Have a nice day

Jun Zhang

[MattT]

Yea, i came to the same conclusion 2 weeks ago, but why isnt it a problem of the driver? The driver is there to solve problems like this, so the user dont care whats going on inside the black box.

And if the RAM does not work with unaligned stuff, why doesnt the driver add stuffing bytes? I can do it also by myself in the driver lib, but I am not so happy with fixing third party midware and each time i do an update i need to pay attention to this problem.

David Crocker had the same issue by activating newlib on a ST (see Fifth Issue). He fixed it by using replacing memcpy at the point but he also mentioned "-fno-unaligned-access" as option. But it did not work out for me.

https://miscsolutions.wordpress.com/2019/12/27/using-exceptions-in-c-embedded-software/

[ZhangJennie]

The reason why we use memcpy is to improve performance. If not considering the performance, you can change it using for loop. However, I think for loop may decrease the performance much, so we have no plan to change the code in our release.

For our USB demo in MUCX, I have added "-mno-unaligned-access" to make sure compiler not generate unaligned memory access instruction. However, for the new lib, this compiling option can not cover it. Therefore, please re-compile the lib . under the "-mno-unaligned-access"

[svoulaz_ik]

Hello,

I jump into this quite old topic because I found the same issue while trying to use libc (instead of libc_nano) in a project of ours. While it is true that the USB SRAM is, by default, mapped to a Device memory (and, as such, does not support unaligned access), the LPC55s69 reference manual states that:

[start of quote]

Note: USB SRAM is mapped in the so-called “Peripheral” Memory Region of both CPU0
and CPU1. The “Peripheral” memory region (which extends from 0x4000_0000 to
0x5FFF_FFFF) is considered as “Device” type by default and USB SRAM is located from
0x4010_0000 to 0x4010_3FFF. “Device” memory regions do not allow “unaligned”
accesses by default. However, by using the Memory Protection Unit (MPU), the “Memory
Type” of an address space (except for the last 0.5 GB of the 4G space) can be modified.

[end of quote]

So, I started looking at ARM documentation for the ARMv8-M MPU and I ended up with a viable solution that allows using non-aligned accesses with USB SRAM. One region of the MPU, mapped to USB SRAM, shall be programmed as Normal memory, as follows:

ARM_MPU_SetMemAttr(0, 0x44); // Normal memory, non-cacheable (inner and outer)

ARM_MPU_SetRegion(0, ARM_MPU_RBAR(0x40100000, ARM_MPU_SH_NON, 0, 1, 1),              ARM_MPU_RLAR(0x40104000, 0));

ARM_MPU_Enable(MPU_CTRL_PRIVDEFENA_Msk | MPU_CTRL_HFNMIENA_Msk);

This way, the fault on memcpy does no longer occur and the USB driver (msc, in my case), works like a charm.

My two cents...

Stefano

[ZhangJennie]

I just imported a USB demo code with newlib selected

Chang file :usb_device_config.h

/*! @brief LPC USB IP3511 FS instance count */

#define USB_DEVICE_CONFIG_LPCIP3511FS (0U)

/*! @brief LPC USB IP3511 HS instance count */

#define USB_DEVICE_CONFIG_LPCIP3511HS (1U)

build and download code. there is no error.

Can you test the same?

Jun Zhang

[MattT]

Still having the same problem. I am using the "dev_cdc_vcom_bm" Example from SDK 2.9.1.

[MattT]

Hi,

which flags do you use to compile it with "NewLib (none)". If i create a fresh project i run into following errors:

I am using for my project "NewLib (nohost)"

[ZhangJennie]

I use NewLib (none)

Try import a usb demo, during import, select NewLib (none) as my screenshot. See if this works for you?

Jun Zhang

[converse]

It looks like it is more likely to be memory corruption than any issue between newlib/nano and the USB stack. Put a breakpoint on the memcopy call in the failing function, taking a look at the pointers being provided. I’d also check your stack and heap sizes.

[MattT]

Hi,

thanks for your answer.

Because i just run the default NXP project there is noch problem with the Heap (nothing used until it crashed), Stack 6,25%

Anyway the USB driver has its own RAM on the LPC 55S69, so this shouldnt be a issue too.

I found out that the memcpy causes a unaligned memory addess.

He had the same issue by activating newlib on a ST (see Fifth Issue):

https://miscsolutions.wordpress.com/2019/12/27/using-exceptions-in-c-embedded-software/

[converse]

memcpy() is written to correctly take care of unaligned access, so that is not likely the problem. What are the src and dest pointers when the memcpy() fails? 

[MattT]

Here the current varibles: