-
Notifications
You must be signed in to change notification settings - Fork 327
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stm32f429i-discovery/sdram not working #112
Comments
This is a bit confusing, are you talking about the STMicro demo or are you talking about the libopencm3 demo? In the latter case the demo sets up a very simple memory tool for looking at the memory over the serial port, it doesn't do anything with the USB port. |
Sorry I meant ramdisk not sdram . Lack of a readme in the latter may have lead to difficulty in identifying it. If I flash the device I get a new mass storage device: ls /dev/sdc* this gets auto-mounted at /run/media/user/RAMDISK: but if I so much as try to ls anything on it, it falls apart: ls /run/media/user/RAMDISK/* |
Ah, I see. So there are a couple of things here which could use some clarity. First, there are two ARM chips on the Discovery boards, one has the STLink software and the other is the target device. Next, the latest STLINK (V2.1-1) software is mBed compatible. That means when it plugs in you should see three devices. On my system with the 32F469 discovery board I see this:
The target device can be programmed by dropping a binary image on to the mass storage device. The device has to be 'nocache', 'noatime' mounted. You can also connect to it using OpenOCD which will open up a gdb server on port 3333, so you can connect using localhost:3333 as the remote target. And finally the /dev/ttyACMx (usually 0 if its the only one) serial port which is connected to one of the USARTs on the target chip, typically on the Port A pins. Since the '429 board was not originally designed to run mbed compatible firmware you may have to make jumper changes for it to work correctly. There are also updated windows USB drivers (if you have a windows client) which recognize the diagnostic (STLINK) port, the serial port, and the disk drive. In general I ignore the mass storage device, program it using gdb through connection with OpenOCD and use gnu screen to connect to the serial port with |
Thanks. I'm working on Linux too using openOCD and gdb. We are on the same page with that. I have flashed several of the examples from this project , so the default software devices are not relevant beyond what is provided by the STLINK chip. I currently have the ramdisk demo on the board. If I plug in just the STLINK, I get one device. It's a V2 but I don't know a means of getting the minor version numbers.
Now , if I plug in the OTG: (note the for clarity I'm using a different USB port ). It is correctly detected as mass storage, no cache device. Then it starts to go wroing:
/var/log/messages contains some more information:
It looks like some kind of udisk daemon is screwing things up while auto-mounting the device or that the device is not responding correctly. |
This gfvs bug is the cause of the BDVM crap.
|
If I umount /dev/sdc and replug it I can get gfvs off my back. But then a manual mount does not get any further.
Have you been able to mount the ramdisk device provided in the demo? |
I built and flashed the stm32f429i-discovery/sdram demo.
I get a mass storage device showing up and it auto-mounts as vfat on Fedora 23. But if I try to do anything like cat or head on the datafile the I see on the drive I get an IO error.
The text was updated successfully, but these errors were encountered: