I tried to use FileX with USB mass storage, but when I try to initialize the Host USB Controller (with the USB key inserted) I get an error because the USB host controller did not find the USB device.
The flash drive is powered. Is there something wrong with the configuration?
Hello Paolo!Thank you for your message and reaching through our Renesas Community. First, would like to confirm the hardware module/ part number that you are currently using. Would like also to know if you have ran through and check this document below:https://www.renesas.com/us/en/document/apn/usbx-host-class-mass-storage-module-guideHope this helps.
If this response, or one provided by another user, answers your question, please verify the answer. Thank you!
Renesas Engineering Community Moderatorhttps://community.renesas.com/https://academy.renesas.com/https://en-support.renesas.com/knowledgeBase/
I use S7G2 with SSP 2.4.0
I just read that document but I didn't find any errors.
Is it the code example or have you integrated this code into your own program?
If it's your own program, please try the sample code provided by Renesas and check if it works out of the box . https://www.renesas.com/us/en/document/scd/usbx-host-class-mass-storage-module-guide-rev105-sample-code?r=1054631
Also if it's your program, did you change any setting in the FileX/USBX stacks in the visual configurator? If yes, please provide the screenshots of the properties so I could try to reproduce your issue here.
By the way, is it a custom board or some development board like SK-S7G2 or DK-S7G2?
Your VBUSEN signal is not used. Normally this controls 5V supply to a attached usb device. What's your connection like?
I use a custom board. I didn't have a code example, I had integrated in to own program.
Now I use a signal analyzer.
I will keep you updated.
I do not use VBUSEN because the 5 V is always on.
I found that it is not a hardware problem if I remove all threads except the one that uses the USB mass controller detection works.
I have to remove these threads, if I disable them it still doesn't work and I don't understand why.
Do you have any ideas?
The type of your error and the result of your tests make me think that the problem is with the memory usage. Probably some of your threads use too much of RAM so the USBX and thread stacks overlap. Please check if you set enough stack and heap sizes, and if their overall size doesn't exceed the RAM volume.
The RAM is 99% because I use all free ram for heap (I changed the script file).
I tried increasing the main stack but it doesn't work.
How can I tell if there is an overlap between USBX and thread stack?
In the same "Memory Usage" view you can check the memory allocation of all the objects and symbols of your program, there you will probably find the overlap.
Also I'd recommend you to use the SSP configurator to change the heap and stack size, probably in this case it allocates the memory more correct than if you change the .ld script manually:
As per your advice, I put the default script back in.I did this type of check and saw no overlap (I thought there was something automatic).It is a very big program and there are a lot of variables.
But isn't the linker's job supposed to be to not create overlaps?
UPDATE: I set a breakpoint in the MPU Stack Error interrupt but it was not triggered.
Yes, it's hard to reveal the issues like this. Linker only checks the static memory allocation but if you allocate the memory dynamically, I'm not sure if linker can manage such kind of overlapping.
I think there is no MCU stack overflow issue. It should be in the dynamic memory allocation (if it is the memory issue at all). Try to check the places in your code where you allocate the big chunks of dynamic memory and check if their total volume is less then the heap size. Probably you will even need to check the FSP generated files to see what is done there.
I don't use dynamically allocated memory in my code directly, but SSP/ThreadX... can. I think that code generates an error if it fails to allocate, though (this doesn't happen).
Also by disabling threads these don't run and should not create dynamic allocations.
At this point, I'm not sure if it's a memory problem I've also tried increasing the interrupt and thread priority, but it didn't change anything.
I don't know what to do anymore.
It's hard to find the solution not seeing the code. I understand that you can't provide it, so I can only suggest the steps which I could do in your situation.
Paolo said:The problem is in these lines of code:
The problem is in these lines of code:
I would first try to compare the values of these variables "_ux_system_host_class_storage_name" and "host_class" manually. Maybe you will notice the difference, and it will give you some idea. Also if they are totally different, and it's really an overlap issue, you may notice with what part of the memory these variables match.
Then do the same checking without other threads when it works to see what these values should be.
Also notice the addresses of these variables in both cases, maybe this also will give you some clue.
I would check the USBx memory pool size. Is it properly sized?
Does other threads use USB?
The pool is common for USBx host and device stacks.
I must increase USB memory pool size to 54K.
I also use the other USB port but even deleting that thread doesn't work.
When it works the variables have the value ux_host_class_storage.
The strange thing is that now when it fails I no longer go into the ux_system_host_change_function, where the comparison was happening with error (I also tried loading backup versions from days ago).
I'm really demoralized, maybe then it's a cavity.
I'm investigating the USB sources, but there are many and I don't know the USB protocol .
In the S7G2 the internal SRAM although contiguous actually consists of a SRAMHS block and an SRAM0/SRAM1 block. The boundary between the two blocks is at address 0x20000000. If an unaligned memory access is made across this boundary there will be an issue as some data is in one block and the rest of the data is in the other. In this instance the data may not be read correctly.
When you have the issue do you have USB memory etc spanning this boundary? If you do then this could be an issue. Moving the buffer to prevent it crossing the boundary would fix this issue. This can be done by adding dummy RAM data to span the boundary instead.
Technical bulletin about this: