I have an Arduino rig setup that has stepping motors moving in X and Z. I'm using with a serial sensor to measure values at locations of an object, ie. move the object, keep the sensor stationary.
Writing to the USB file works "sometimes".
My determination is it will fail if the stepping motor has to move a long distance in X, Z. If it's in small steps it's fine.
A file write error causes the Arduino to crash (you see a flashing red light, app stops).
I can't see how one affects the other?!
If I do the sensing and don't write to the file, it moves around the object perfectly. When I enabled the file writing, it fails when the stepping motor is on long movements.
What are your thoughts? How can one affect the other?
[Seriously been considering if it's getting too hot from the stepping motor that affects the Arduino ports, or some kind of voltage spike takes it out, ... yeah getting desperate!]
Code snippets:
USBHostMSD msd;
mbed::FATFileSystem usb("usb");
mbed::DigitalOut otg(PB_8, 1);
...
Serial2.begin(4800,SERIAL_7E2);
while (!Serial2) {
; // wait for serial port to connect. Needed for native USB
}
//usb
pinMode(PA_15, OUTPUT); //enable the USB-A port
while (!msd.connect()) {
delay(1000);
}
int err = usb.mount(&msd);
if (err) {
//Serial.print("Error mounting USB device ");
//Serial.println(err);
while (1);
}
...
void WriteLog (char * message)
{
int err = 0;
FILE *f = NULL;
if (ignore_log)
{
return;
}
f = fopen("/usb/rig_log.txt", "a+");
if (f == NULL)
{
return;
}
err = fprintf(f, message);
if (err < 0)
{
//
}
fflush(f);
fclose(f);
}
Hi Stu. Take a look here Unreliable file writing on connected flash drive Try one of the usb drives mentioned to eliminate that as your problem. Also, remove the fflush() call as chan's FAT library flushes for you and I've found fflush() can mess with the reported file size.
p.s. I'm using Kingston 64GB DataTraveler Micro Metal Flash Drive USB 3.2 and I'm having no issues
Thanks for connecting to me to those topics! I will swap out my USB and see.
Good reading, hey -- can you tell me why I need these lines of code (which I'm not using right now, but they are in the sample codes I've read).
At the time of enabling the USB-A port I see this line called just afterwards, what is HIGH and LOW doing? I guess it's HIGH by default perhaps? Should I start calling it?
digitalWrite(PA_15, HIGH);
At the time of opening the file I see this line called just before. I can't see any purpose for it, the variable "file" isn't referred to anywhere as everything refers to FILE *f , so I just deleted that line. Should I start using it?
This turns on the power to the USB-A port (HIGH) or turns it off (LOW). It's turned on in the mbed code so isn't strictly needed (I still include it)
You can use the fs_file_t handle instead of the standard FILE *f if you wish. It's not used in the examples. You'll also see some stuff like DIR that's been carried over from one example to another even though not used.
That's disappointing, it has been the cause of most people's issues.
The next thing I would try is opening your log file once in setup with FILE *f global and don't flush or close in your WriteLog func.
If that doesn't help, it's possible there is blocking code in the stepper driver (don't use steppers so just a guess) that's not a problem with short moves but causes issues for the USB writes on long moves. There is certainly blocking code in the USB write code, which is unacceptable in my system, and this drove me to implement this:
You could move your logging to the M4 core and use SRAM3 shared memory to pass the data. This works incredibly well for me but is not a quick fix. Happy to assist if you decide on this approach.
This WORKED! Opening the file at the start, running the system and then saving at the end -- and DO NOT use fflush, just fclose! To be honest I think fflush was my nemesis all along. With it used, I saw the red light of doom, without it was smooth writing. I consider this workaround resolved! [Along with a new Kingston USB flash drive to boot]
always had my log opened once so fflush() just gave me iffy filesize data. I notice the USBHostMbed5 examples use fflush() but only for stdout. So glad you've nailed it
Not great news. Have been struggling with USB-A writes still. Initially I thought it had worked. But when testing in ernest it hadn’t. Do you have any advice with streaming data off from in memory to an app over Bluetooth, or sending data to the cloud via an API (I haven’t tried getting the unit to do an internet connection before). I was considering an SD card approach but wondering if that will send me down the same alley. Any advice much appreciated!
I've not tried the Bluetooth module, nor the cloud, but do make a lot of use of the WiFi.
If you can't get USB-A working I'd go down the SD card route (seen reports of that working ok) or a data logger module from someone like openLog
always had my log opened once so