Page 1 of 1

CSUD writes to 000f0000 and 00050070

Posted: Sat Sep 07, 2013 2:28 pm
by hldswrth
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).

Re: Crash when dynamically loading CSUD

Posted: Sat Sep 07, 2013 6:18 pm
by DexOS
I think the problem could be your using a later ver of the boot loaders.
Try this: ... 12#p405612

Re: Crash when dynamically loading CSUD

Posted: Sun Sep 08, 2013 6:26 pm
by hldswrth
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?

Re: CSUD writes to 000f0000 and 00050070

Posted: Mon Sep 09, 2013 6:08 pm
by DexOS
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.

Re: CSUD writes to 000f0000 and 00050070

Posted: Mon Sep 09, 2013 8:08 pm
by phil95
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 ?

Re: CSUD writes to 000f0000 and 00050070

Posted: Fri Sep 13, 2013 4:09 am
by xlar54
I dont know if Im having the same problem, but csud is definitely causing a hang for some reason. Ive pulled the latest from:

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?

Re: CSUD writes to 000f0000 and 00050070

Posted: Fri Sep 13, 2013 5:55 pm
by DexOS
Are you sure its not the bootloader problem stated above ?.

Re: CSUD writes to 000f0000 and 00050070

Posted: Mon Sep 16, 2013 7:51 am
by phil95
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

Re: CSUD writes to 000f0000 and 00050070

Posted: Mon Sep 16, 2013 5:43 pm
by hldswrth
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. ... gnware20.h line 18:


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

Re: CSUD writes to 000f0000 and 00050070

Posted: Mon Sep 16, 2013 8:55 pm
by xlar54
Terrific. I will definitely try this tonight!

Re: CSUD writes to 000f0000 and 00050070

Posted: Tue Sep 17, 2013 6:13 am
by xlar54
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!

Re: CSUD writes to 000f0000 and 00050070

Posted: Wed Oct 23, 2013 7:55 am
by phil95
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(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.