Format filesystem from linux (or image file to dd?

Short Version:

Does anyone know a way to format the deviation filesystem with mkdosfs, or could anyone provide a raw image of a filesystem for Devo10 (or 7e) which I could install with dd?

Longer version:

I'm working on a port of Deviation to the STM32F3 discovery, with an sst25vf032 flash chip added to it.

I'm at the point in bootup where I need a valid filesystem on the flash, and I'm having trouble getting the mass storage stuff ported (in particular, the difference between the block sizes I can get mass storage to work with, and the erase size of the flash)

What I'd really like to do is be able to get an image file on my linux dev machine, and then upload it to the flash by alternate means, such as making a little program that just dumps usbcdc packets to the flash in order received.

I'm hearing that formatting the flash with linux is problematic; it seems to me that a valid filesystem formatted from windows could be copied back out with dd, loop mounted, erased, and compressed to a tiny size for distribution.

it's 1am here so I can't do it just now, but if no one has done it by lunchtime tomorrow when I get home I'll dd the 7e usb drive for you

Thanks, that would be really helpful to have a known good one.

I sort of faked a small FAT12 image and filled it up, and wrote some code to let me write to the flash.

But the sst25vf032 is not accepting writes. Really kicking myself because I've done a project with those before (why I had them on hand) and should have all the issues figured out. But not.

Wrote some code so I can manually send SPI commands. I'm unlocking the status register, clearing the BPL bits, enabling the write latch, and I think writing. But no matter what I (or the Deviation code) do, I never get back anything but blank memory. Yet I can read the status register and idcodes...

Problems it isn't:

1) The F3's determination of 8-bit or 16-bit SPI transfers based on SFR access width (already fixed that...)

2) Confusion over Deviation's inversion of all the data bits - ie, Deviation sees erased flash as 00 while I see it as ff, but it's the same issue in both programs. (Though I'll admit I'm still curious why that is done)

umpteen hours later, I notice that the ground lead to the flash daughterboard is soldered to the empty hole next to the ground pin and not actually to it Connect the grounds with a clip lead and suddenly my 2-byte test writes work.

And that's an old classic... circuits which "sort of" work when missing power or ground.

While the iron is hot, I'll add the decoupling caps, too.

well you probably don't need it now lol, but here you go anyway

Actually, I still do, so many thanks!

Deviation would mount my crafted filesystem, but it's complaining about missing bmp files (found in yours) so I'll need to debug that.

But it's really useful to have a reference of a known-good filesystem structure that works on an actual devo tx. (Incidentally, I tried erasing and zeroing a copy of yours to have just the structure, and it compresses down to 4k, which might really be viable for distribution if a perfectly reliable linux format command can't be found)

And then I just need to get it talking to this 1.8" color SPI LCD (conveniently the same resolution when initially ignoring color, and looks nice running Arduino demo code), transplant the old futaba sticks to a project box, wire it up, get minimal timers and interrupts going, transplant an RF module, and fly

(Once I get a working circuit I'll do a PCB smaller than the Discovery eval board, at which point transplanting the sticks won't be necessary, it would be more like a brain transplant to an existing older TX)

so i take it your project is a complete tx? do you have a blog or anything showing your progres etc?

That's basically the goal, but I've only been working on it for a few days.

It will probably get it's own thread soon - this one was really going to be about formatting the filesystem from linux, or alternatives thereto.

The inversion was not an issue, since I used the existing SPI routines which do it. It was just surprising - but thanks for explaining the reason. I got 4K blocks working, but my residual problem with mass storage is I think inherited from the example code I started with. I was trying for something cleanly libopencm3 without the legacy ST code in the existing one, though maybe adapting that to the ST code for the F3 would be more effective.

At any rate, I have a temporary workaround with a cdcacm based flasher mini-firmware I use with dd, so it's no longer a blocker for me.

I'm curious if you think the wk2601 as an enclosure with a brain transplant would be a good platform... they seem inexpensive. Is the existing LCD fixed function or pixelated?