hldswrth
Posts: 108
Joined: Mon Sep 10, 2012 4:14 pm

CSUD writes to 000f0000 and 00050070

Sat Sep 07, 2013 2:28 pm

I've been happily working on a bare metal project for a year on and off, using CSUD for the keyboard, for which I'm very grateful. However a couple of weeks ago all that stopped. I decided to modularise my kernel, and as part of that I moved the CSUD library from being statically linked to the kernel to being statically linked to a module that my kernel dynamically loads. Since then, I've seen two issues, both apparently in the same function (HcdChannelSendWaitOne). The keyboard works just after boot so functionally it appears OK, however pretty soon there is either a timeout waiting for a response from the keyboard, or the screen goes blank.

I've tried to narrow the issue down, and it appears to be in one piece of code which waits for the completion of a split transaction. All that code does is to read and write three USB Host registers (interrupt, split control, characteristic). I can't see how this code could cause the screen to blank. I have exception handlers installed which ought to prevent this happening for any software reset.

Since this happened I've tried out my rasbian image and that does not seem to have any such issue with the keyboard. I've also gone to an older version of my kernel with the statically linked library and that does not appear to exhibit the issue either. I've dumped the loaded binary and checked that the relocation has worked properly.

I've tried everything I can think of to diagnose this, I've checked that the code is not being modified in any way, but am now at a loss as to why I'm getting this issue. Is it possible its actually a hardware/power issue? Seems odd that raspbian would work in that case, unless its to do with the way that CSUD is hitting the registers.

Has anyone had any sort of issue with CSUD along these lines? I'm running out of things to try. I guess I may have to bite the bullet and go back to having it statically linked into my kernel (assuming that continues to work of course).
Last edited by hldswrth on Sun Sep 08, 2013 10:58 pm, edited 1 time in total.

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: Crash when dynamically loading CSUD

Sat Sep 07, 2013 6:18 pm

I think the problem could be your using a later ver of the boot loaders.
Try this: http://www.raspberrypi.org/phpBB3/viewt ... 12#p405612
Batteries not included, Some assembly required.

hldswrth
Posts: 108
Joined: Mon Sep 10, 2012 4:14 pm

Re: Crash when dynamically loading CSUD

Sun Sep 08, 2013 6:26 pm

I tried the firmware you referred to and it does stop the reset errors. However I'm still suffering from a timeout fairly soon after starting. It looks like its my issue with memory corruption happening - if I force the keyboard module to be loaded much higher in memory I don't see any errors.

Thanks for the tip :) Now I just have to track down a seemingly random memory write. I'm pretty certain its coming from inside CSUD. I've tried allocating 1MB before loading it, and set that 1MB to all 0xAAs. I check that memory before and after calling KeyboardPoll, and at some point that memory gets changed before the call returns. For example in my last attempt, I found that after calling KeyboardPoll repeatedly for two minutes the following gets written:
0x000f0000: 00000000 000000e4 aaaaaaaa aaaaaaaa
That could quite possibly be the USB host writing the result of a request, and somehow getting the memory location corrupted - or else for some reason CSUD is setting that address into the host register.
[Edit]another memory overwrite:
0x00050070: 00000000 000000e4 aaaaaaaa aaaaaaaa

[edit2] Its always one of these two addresses that get corrupted, apparently by the USB host writing to them, as there's nothing in the CSUD code writing to these addresses. I've checked that the DMA address set for USB operations (i.e. value written to 0x20980514) is always set to either 0x7bd8 (stack) or 0x139f28 (CSUD heap). However in the middle of waiting for a response from the USB keyboard, memory at either 0x000f0000 or 0x00050070 gets written with the response from the keyboard - in fact I've caught it happening with a key pressed and that value appears in this memory location.
[edit3] I've gone back to statically linking CSUD into my kernel and I still see these memory addresses getting written to.

So any clue as to why the USB host would write to one of these two specific fixed addresses?

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: CSUD writes to 000f0000 and 00050070

Mon Sep 09, 2013 6:08 pm

Not sure why its writing to those address, but i will take a look, if i find anything i will let you know.
Also if you find anything let us know, as i would be interested to fine out why too.
Thanks.
Batteries not included, Some assembly required.

phil95
Posts: 141
Joined: Wed Sep 12, 2012 8:10 am
Location: Paris

Re: CSUD writes to 000f0000 and 00050070

Mon Sep 09, 2013 8:08 pm

Hello,
I'm working on my own USB driver (since a lot of month...)
and I have encountered the same(?) problem:
Memory was corrupted after a lot of time, but the same prog halt
after the same amount of data.
After a lot of search, and a lot of tries, I found that total FIFO size is limited
to 4096 bytes (BCM2835-ARM-Peripherals.pdf P 201).
The size of the three FIFOS is limited to 4096 bytes each and the sum
is limited to 4096 bytes.
In my prog, I have limited the 3 Fifos to 1024 bytes instead 20480 bytes
My soft is today working correctly, and I have no more memory corruption.
I have not tested with CSUD software, but may be you can test
mofifying fifosize in designware.h ?
Cordially
Philippe

xlar54
Posts: 50
Joined: Tue Aug 20, 2013 5:08 am

Re: CSUD writes to 000f0000 and 00050070

Fri Sep 13, 2013 4:09 am

I dont know if Im having the same problem, but csud is definitely causing a hang for some reason. Ive pulled the latest from:

https://github.com/Chadderz121/csud

Its hit or miss. Sometimes it will work, and sometimes it wont. Apparently, it depends on if I add more code to my application. Is the code maintainer actively looking into issues with this? Git says last updates were around 4 months ago.

Also, are there any other options right now?

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: CSUD writes to 000f0000 and 00050070

Fri Sep 13, 2013 5:55 pm

Are you sure its not the bootloader problem stated above ?.
Batteries not included, Some assembly required.

phil95
Posts: 141
Joined: Wed Sep 12, 2012 8:10 am
Location: Paris

Re: CSUD writes to 000f0000 and 00050070

Mon Sep 16, 2013 7:51 am

After a lot of test, I have still the same problem.
I'm using only the first channel, but when the problem arrives,
all channel descriptors are corrupted.
I'm seeking on another track, I have some ideas.
I will repost if I find something
Philippe

hldswrth
Posts: 108
Joined: Mon Sep 10, 2012 4:14 pm

Re: CSUD writes to 000f0000 and 00050070

Mon Sep 16, 2013 5:43 pm

I've tried reducing the size of the FIFOs in CSUD by defining the sizes all as 1024 as suggested, and so far (fingers crossed) have not seen those locations modified nor any other corruption happening. According to the Hardware register, the total FIFO depth is 4080 so setting 3 FIFOs to 1024 bytes seems safe enough, setting them to 20480 as in the version of CSUD that I have seems obviously wrong. Will report back if I see any issues with this.

The change is in designware20.h, replace the 20480's with 1024.
https://github.com/Chadderz121/csud/blo ... gnware20.h line 18:

#ifdef HCD_DESIGNWARE_20

// Total size of the FIFO is 4080 according to the hardware register.
#define ReceiveFifoSize 1024 /* 16 to 32768 */
#define NonPeriodicFifoSize 1024 /* 16 to 32768 */
#define PeriodicFifoSize 1024 /* 16 to 32768 */

While I'm at it I also had to comment out this line towards the end of Keyboard.c (KeyboardGetKeyDown)
https://github.com/Chadderz121/csud/blo ... keyboard.c line 357:

// if (index >= keyCount) return 0;

Because when one key is pressed, for my keyboard its not being returned in the first element of the data array.
Last edited by hldswrth on Tue Sep 17, 2013 12:43 am, edited 1 time in total.

xlar54
Posts: 50
Joined: Tue Aug 20, 2013 5:08 am

Re: CSUD writes to 000f0000 and 00050070

Mon Sep 16, 2013 8:55 pm

Terrific. I will definitely try this tonight!

xlar54
Posts: 50
Joined: Tue Aug 20, 2013 5:08 am

Re: CSUD writes to 000f0000 and 00050070

Tue Sep 17, 2013 6:13 am

Sadly, the problem persists. Using the older boot loaders, and changing the FIFO values seem to have no impact. As soon as I enable the keyboard, my video routines stop functioning. But thank you for all your help!

phil95
Posts: 141
Joined: Wed Sep 12, 2012 8:10 am
Location: Paris

Re: CSUD writes to 000f0000 and 00050070

Wed Oct 23, 2013 7:55 am

Hello,
After a lot of tests, I think, I have solved the corruption problem (in my case). I have updated my init function with the following instructions.

UsbPoke(COREAHB, 0x31);
UsbPoke(COREUSB, 0x1700);
UsbPoke(HOSTFRAMEINTERVAL, 7500);
UsbPoke(HOSTCONFIG, 0x0);
...
UsbPoke(COREOTGCONTROL, 0x1c0000);

These instructions were added after comparing my driver init and raspbian registers values while running.

With these modifications, my driver can read USB memory stick at more than 10 Mbytes / sec during hours without any error or corruption.

I don't use CSUD driver; I'm not shure, but I think that the CSUD driver user other init values.

Philippe

Return to “Bare metal, Assembly language”