ChibiOS Free Embedded RTOS

ulikoehler,
I will need to translate your linker script to EmBlocks settings, but all this looks very useful for me.

Thanks!!!

thanks Giovanni , ulikoehler and chudik for you great advice.

@chudik

we used relatively small (and not so expensive) FRAM for the temporary buffer

that's a really good advice , i should try this method in my next board , but first find a way to put this method into my realtime system, because transfer data from one memory to another take time , Although stm32f4 takes advantage of having DMA , i shuld manage it by DMA , it would be challenging because i just used HAL library of chibios.

@Giovanni and ulikoehler
yes the problem was size of data buffer , it should be 512 bytes.

but there is question , have you ever tried to use data which is saved in sd card in Computer(data is saved raw , without FATFS) ?? the SD is raw and windows wants to format it , i tried to access to raw drive directly by C# , but something that i don't know is going wrong.

@deadlyboy

Yes, there's a problem with Windows there. Users might inadvertently format it, destroying some of the data.
I have only used it on Linux, which doesn't display a "Do you want to format this?" dialog right away at least. I don't know of any direct way to prevent Windows from showing this.

I can think of a hack though: As long as you preserve a valid (yet empty) FatFS instance, you should be able to overwrite the free blocks with your custom data. I don't know too much about the structure of FAT, but probably you only have to start at a certain offset (and - maybe - avoid overwriting certain block numbers).

I recommend you overwrite a fresh SD card with random-ish, but predictable values, create a FAT on partition 1 and check which blocks have been changed. These are the blocks you should NOT overwrite.

Steps:
You can modify my Tool SDCheck (https://github.com/ulikoehler/SDCheck) which I use to check for bad blocks in order to check for blocks differences afterwards (modifying it will have medium complexity. Note that the core SDCheck concept is to generate two 100% equivalent streams of pseudorandom numbers by using the same seed.).
Then, create a MSDOS partition table and format partition1 with FAT.
Use the modified SDCheck to print a list of blocks with differences. Repeat with a different seed.

This is certainly not an advice I'd give to an industrial user without testing it beforehand (and probably not even then - maybe different FAT implementations overwrite some of my data blocks). When using this method, make sure the user never ever places a file on the mounted filesystem.

You could also try using a raw partition, but Windows will probably try to format it anyway. Maybe a linux swap partition will note make Windows show the format dialog !?!

Alternatively, you could use the write protection switch when inserting the card into the PC, if your application allows that.
Alternatively, you could avoid inserting the SD card completely by using the STM32 USB in device mode and emulate a mass storage device. This will be incredibly complex but allow for a certain amount of flexibility.

Best regards

ulikoehler wrote:I can think of a hack though: As long as you preserve a valid (yet empty) FatFS instance, you should be able to overwrite the free blocks with your custom data. I don't know too much about the structure of FAT, but probably you only have to start at a certain offset (and - maybe - avoid overwriting certain block numbers).

It might be as simple as formatting the partition table on the SD card appropriately - I suspect its the absence of a partition table which provokes Windows desire to format the card. You can then define a partition type which Windows can't access; or if necessary a small partition to keep Windows happy, and a large non-standard partition for your data.

You might be able to define the bulk of your SD card as a single large file, identify the area on the card where this file exists, and write data to that area. Then in Windows you can directly access the file.

@steved

I agree about having a partition table might solve the issue.

When you write to a large file, you have (as far as I know) to update the FAT headers - therefore you have exactly the same issues in case of power failure. You might be able to simplify the file system implementation when supporting only one file (e.g. constant file start offset, no fragmentation), but it might still depend on valid FAT headers which might be damaged under some circumstances.

Best regards

ulikoehler wrote:When you write to a large file, you have (as far as I know) to update the FAT headers - therefore you have exactly the same issues in case of power failure. You might be able to simplify the file system implementation when supporting only one file (e.g. constant file start offset, no fragmentation), but it might still depend on valid FAT headers which might be damaged under some circumstances.
Best regards

I was thinking that this 'large file' would be just a permanently assigned area on the card, probably read-only from Windows' perspective, with its parameters never changing. The Chibi program would then do what it liked within the file's data area, but never touch the FAT headers. As long as both ends agree on the 'file' format, there is no need to update the main FAT entries.

ulikoehler wrote:@Chudik: In a STM32F0 project I have successfully used the ST library (from STM32F0Cube) without significant modifications. I mainly copied code from the example from STM32F0Cube.

Finally I came to the part of my project where I need to use EEPROM.
ulikoehler, did you use project example FLASH_WriteProtection as a starting point? Or something else?

I can't figure out yet, what part I should use in my project
Could you show all your eeprom.h and eeprom.c files?

Found that eeprom.c in one of the projects. It is about I2C/SPI EEPROM, not about internal Data EEPROM from 2K to 16K depending on particular chip.
Seems like need to open another thread about working with the internal Data EEPROM.

You can just use the ST EEPROM library without any major modifications. You only need to modify the linker script to e.g. for a 16kib flash uC only use 14kib so the remaining two pages are available for the EEPROM emulation.

best regards,
Uli

@Chudik: sorry, missed your previous message. I'm at a fair at the moment so I can only answer shortly.

I did not use a particular example as a starting point. I havent used EEPROM emulation with ChibiOS 3.x yet. As far as I know the code I posted in this thread before contains all modifications I made to the ST EEPROM emu library. Basically you need to tell it which pages to use. Remember to use FLASH_Unlock(), for which you need a small part of the HAL.

What's the exact issue you are having? Google, for example, for "STM32F1 EEPROM emulation library". You'll find it on the ST website, or it might be integrated into STM32Cube