Anyone want to give this code a try?

As stated by jpearmen - this code does pose a risk to your device - if used incorrectly. I assume no responsibility for any damage your device may endure.

I got some time today to look in to writing a file-system module for easyc and stumbled accross some code (I am pretty sure its from the Cortex-M3 SDK) that can be used for reading\writing to the flash memory - and a host of other sorts of things. I found it specifically when I was browsing a “Hardware Abstraction for VEX” project on GitHub:

I found a file under fwLib (Firmware Library), hax/arch_cortex/lib/fwlib/inc/stm32f10x_flash.h

Here are some APIs I see it has defined:

void FLASH_SetLatency(uint32_t FLASH_Latency);
void FLASH_HalfCycleAccessCmd(uint32_t FLASH_HalfCycleAccess);
void FLASH_PrefetchBufferCmd(uint32_t FLASH_PrefetchBuffer);
void FLASH_Unlock(void);
void FLASH_Lock(void);
FLASH_Status FLASH_ErasePage(uint32_t Page_Address);
FLASH_Status FLASH_EraseAllPages(void);
FLASH_Status FLASH_EraseOptionBytes(void);
FLASH_Status FLASH_ProgramWord(uint32_t Address, uint32_t Data);
FLASH_Status FLASH_ProgramHalfWord(uint32_t Address, uint16_t Data);
FLASH_Status FLASH_ProgramOptionByteData(uint32_t Address, uint8_t Data);
FLASH_Status FLASH_EnableWriteProtection(uint32_t FLASH_Pages);
FLASH_Status FLASH_ReadOutProtection(FunctionalState NewState);
FLASH_Status FLASH_UserOptionByteConfig(uint16_t OB_IWDG, uint16_t OB_STOP, uint16_t OB_STDBY);
uint32_t FLASH_GetUserOptionByte(void);
uint32_t FLASH_GetWriteProtectionOptionByte(void);
FlagStatus FLASH_GetReadOutProtectionStatus(void);
FlagStatus FLASH_GetPrefetchBufferStatus(void);
void FLASH_ITConfig(uint16_t FLASH_IT, FunctionalState NewState);
FlagStatus FLASH_GetFlagStatus(uint16_t FLASH_FLAG);
void FLASH_ClearFlag(uint16_t FLASH_FLAG);
FLASH_Status FLASH_GetStatus(void);
FLASH_Status FLASH_WaitForLastOperation(uint32_t Timeout);

Which handles flash memory IO - also, there are some files there for programming the interrupt timer and applying the ISRs which handle them - this could introduce a lot of multi-threading features in to easyc. I haven’t done any kernel development on an embeded system (and have done very little on the x86 architecture) so it would definitely be a challenge for me.

Anyway, I don’t have access to my schools cortex till Monday (HOPEFULLY, if the BC Teacher’s Foundation doesn’t vote to stop all extracurricular activites! [This is a mess in the Canadian BC Education system atm…] ) so I was wondering if anyone wanted to play around with the stm32f10x_flash module. I have prepared a solution but have encountered a small trouble when compiling. I must define one of these macros before compiling, they describe for which model the module is for (and I don’t know specifically which is used in the vex cortex and am having trouble finding this out): (its probably easier to just trial & error if you’re unsure)

#if !defined (STM32F10X_LD) && !defined (STM32F10X_LD_VL) && !defined (STM32F10X_MD) && !defined (STM32F10X_MD_VL) && !defined (STM32F10X_HD) && !defined (STM32F10X_CL)
  /* #define STM32F10X_LD */ /*!< STM32F10X_LD: STM32 Low density devices */
  /* #define STM32F10X_LD_VL */ /*!< STM32F10X_LD_VL: STM32 Low density Value Line devices */
  /* #define STM32F10X_MD */ /*!< STM32F10X_MD: STM32 Medium density devices */
  /* #define STM32F10X_MD_VL */ /*!< STM32F10X_MD_VL: STM32 Medium density Value Line devices */
  /* #define STM32F10X_HD */ /*!< STM32F10X_HD: STM32 High density devices */
  /* #define STM32F10X_CL */ /*!< STM32F10X_CL: STM32 Connectivity line devices */
  #error "used device must be defined."

If you do decide to play with it, please report your results. I have attached the easyc project files that is setup in the most primitive way possible for testing the flash memory API - I may have missed a few dependancies - you can find them on the GitHub link above. (82.9 KB)

I will give it a try…

The Actual Processor is the STM32F103VDH6.

There has been previous work done with using potentially the Flash Memory of the Cortex for NV Storage, but there a concern about the Cycle-Lifetime of the Flash memory… ( See Thread, Non-volatile storage )

Sorry to hear about the BC Public Schools System… It sounds just about as bad here in Oregon…

Actual processor is STM32F103VDH6 (not 46) which has 384K of flash, a high density device.

I have to warn anyone who dives into these libraries, the flash in the cortex is only rated of 10000 erase/write operations. Code constantly writing to the same page (in this device a page is 2048 bytes) may theoretically cause damage. Lets say you have code writing 10 times per second that does not work quite right and constantly erases the same page, 1000 seconds later (16 minutes) you have potentially bricked the cortex. Now I’m not saying that this will happen but normally we would put some type of flash translation layer between application code and low level flash control. This would perform “wear leveling” and ensure that even when writing to the same logical location a different physical location is used. So if anyone plays with this, concentrate first on reading before writing. I have some experience in this area and do not plan to post any code as I have no desire to be blamed for damaged hardware. For data logging I always try and use external flash.

As an aside, here is a listing of all the object modules contained within the EasyC runtime library, you can see the flash module as well as the other standard library files from STmicroelectronics.

rw-rw-rw- 0/0   6688 Feb 28 07:12 2012 easyCRuntime.o
rw-rw-rw- 0/0   3724 Feb 28 07:12 2012 Accelerometer.o
rw-rw-rw- 0/0  10564 Feb 28 07:12 2012 Clock.o
rw-rw-rw- 0/0   9232 Feb 28 07:12 2012 Comm.o
rw-rw-rw- 0/0   8364 Feb 28 07:12 2012 Config.o
rw-rw-rw- 0/0   1313 Feb 28 07:12 2012 cortexm3_macro.o
rw-rw-rw- 0/0   2684 Feb 28 07:12 2012 Encoders.o
rw-rw-rw- 0/0   4128 Feb 28 07:12 2012 InputOutput.o
rw-rw-rw- 0/0   5316 Feb 28 07:12 2012 Interrupts.o
rw-rw-rw- 0/0   1876 Feb 28 07:12 2012 InterruptWatcher.o
rw-rw-rw- 0/0    695 Feb 28 07:12 2012 LCD.o
rw-rw-rw- 0/0   7348 Feb 28 07:12 2012 Motors.o
rw-rw-rw- 0/0   8372 Feb 28 07:12 2012 OI.o
rw-rw-rw- 0/0   3388 Feb 28 07:12 2012 Print.o
rw-rw-rw- 0/0   3836 Feb 28 07:12 2012 QuadEncoders.o
rw-rw-rw- 0/0  13116 Feb 28 07:12 2012 stm32f10x_it.o
rw-rw-rw- 0/0   4536 Feb 28 07:12 2012 ddt_support.o
rw-rw-rw- 0/0   4788 Feb 28 07:12 2012 UltraSonic.o
rw-rw-rw- 0/0   3808 Feb 28 07:12 2012 Gyro.o
rw-rw-rw- 0/0   5376 Feb 28 07:12 2012 Mathematics.o
rw-rw-rw- 0/0   9260 Feb 28 07:12 2012 SerialPorts.o
rw-rw-rw- 0/0  13216 Feb 28 07:12 2012 I2C.o
rw-rw-rw- 0/0  17572 Feb 28 07:12 2012 SmartTasks.o
rw-rw-rw- 0/0   6988 Feb 28 07:12 2012 stm32f10x_adc.o
rw-rw-rw- 0/0   2617 Feb 28 07:12 2012 stm32f10x_dma.o
rw-rw-rw- 0/0   2038 Feb 28 07:12 2012 stm32f10x_exti.o
rw-rw-rw- 0/0   6132 Feb 28 07:12 2012 stm32f10x_flash.o
rw-rw-rw- 0/0   3984 Feb 28 07:12 2012 stm32f10x_gpio.o
rw-rw-rw- 0/0   6104 Feb 28 07:12 2012 stm32f10x_i2c.o
rw-rw-rw- 0/0    705 Feb 28 07:12 2012 stm32f10x_lib.o
rw-rw-rw- 0/0   6516 Feb 28 07:12 2012 stm32f10x_nvic.o
rw-rw-rw- 0/0   6256 Feb 28 07:12 2012 stm32f10x_rcc.o
rw-rw-rw- 0/0   4768 Feb 28 07:12 2012 stm32f10x_spi.o
rw-rw-rw- 0/0   1687 Feb 28 07:12 2012 stm32f10x_systick.o
rw-rw-rw- 0/0  16440 Feb 28 07:12 2012 stm32f10x_tim.o
rw-rw-rw- 0/0   5600 Feb 28 07:12 2012 stm32f10x_usart.o

Sorry, must my deteriorating eye sight… I guess a “4” and an “H” look a little alike… :wink:


Didn’t mean to be picky, just wanted the correct number published. Here’s a picture if anyone is interested.


Not a Problem… You NEED to be Picky, I don’t think Processor STM32F103VD46 exsists, but if it did, People would get the Wrong Documentation…

I was lamenting the fact that I opened my Cortex and looked at both the Master Processor and the User Processor and wrote the Part Number down Wrong… It’s Bad Eye Sight or a Confusion of Numbers and Letters…

Thanks for the heads up guys! :slight_smile: I am aware that most flash memory modules do have a max # of write cycles so I will be careful with this.

I still plan to hack into the firmware though, lol xd. I will definitely be more careful though. (I don’t plan on performing frequent IO to the device. - I am not programming an RTOS) You make a good point about remapping addresses as to avoid writing to the same physical addresses to expand the life-time of the device. Also I do plan on writing a memory caching system - I wouldn’t expect someone to use the device as a heap of memory. Writing should be done during initilization and deinitialization and, ofc, per every number of write cycles. But, as I said, I am not building a RTOS and wouldn’t ever consider writing as frequently as 5 times a seconds.

Mind you, 10000 write cycles is disappointing.

This isn’t for data-logging but rather for use with AI components of ones robot. I specifically need to serialize some structures and do not plan on doing any writing however I neither plan to implement half a file system either.

And thanks for looking in to it MarkO & jpearman

One thing you could do for development would be to buy an eval card for the STM32, it would not run EasyC code properly (perhaps not at all) but you could get the flash library built without any potential damage to the schools cortex.

One candidate could be this. There are others in the $30-$50 range.

I don’t actually think it will be that hard to get going, the flash starts at memory address 0x8000000, for ROBOTC (in the latest versions) the VM is in the area 0x8000000 - 0x8018000 (64K), the ROBOTC filesystems is after that and is where user programs are loaded. For EasyC I assume they just load code starting at the beginning. Here is the flash memory map from the datasheet (which if you don’t have then download as it has all of this information). Only 192 flash pages for the STM32 in the cortex, I would use high memory so new program code should not overwrite it unless they perform a complete flash erase before download.

For flash reading you should be able to set a pointer to the address you want and read away :slight_smile:


Thanks for that table! I’ve been looking for it forever (in the wrong places obviously xd) I haven’t been able to find the datasheet either - but now that I know which device we are using I imagine it is much easier to find.

Thanks for suggesting I use a eval card. I’ll definitely looking into getting one. I’ve always wanted to do some low-level programming on embeded systems so I find this a very interesting challenge.

sorry id try it but i cant right now. im not at school anymore!!! :frowning:

This gets very trite but, “Google is your Friend!!”

Google Search “STM32F103VDH6

Resulting in:

STM32F103VD Product Page


STM32F103xC STM32F103xD STM32F103xE: High-density performance line ARM-based 32-bit MCU with 256 to 512KB Flash, USB, CAN, 11 timers, 3 ADCs, 13 communication interfaces


Reference manual: STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx and STM32F107xx advanced ARM-based 32-bit MCUs

The “Table 4” that jpearman posted previously, appears to be from an Older Version of the “Reference Manual”… It Is Now, Table 6, on PDF page 56…

I already found the datasheet, but I should have posted it here for other users to see (as you have).

Thanks :slight_smile:

After Selection the “#define STM32F10X_HD”, I get a Missing Dependency for a Macro Definition, “IS_FLASH_LATENCY(FLASH_Latency)”… Heading for the GITHUB site now…

[EDIT] Actually it is the Assert Macro… Hmm… [/EDIT]

(Attached to this post is a project that should compile.)

Xd That was a tricky mistake of include directives to catch:

What I did was I had to recomment the line

#include "stm32f10x_flash.h"

in stm32f10x_conf.h (I must have uncommented it when I was playing around with something…)

and then add

#include "stm32f10x_conf.h"

to stm32f10x.h

A tricky mess of include directives xd. Sorry I can’t be of much help other than fixing syntax errors here and there - I don’t have access to a cortex at the momment. Thanks for trying this out again MarkO (142 KB)

OK, that did Compile… Also I see some Code in the Main Function…

Looking through the Code, in Module, “system_stm32f10x.c”, there is:

#define SYSCLK_FREQ_72MHz 72000000

Unless there is some sort of Multiplier, the Crystal is 8.000 MHz… This might need to be Adjusted…

I will download and see if the Basic Code will Run…

The Next Step will to be to see if the Flash Code will Initialize…

Then try to Invoke Code to Invoke a Flash Read…

Mark, there is a multiplier of x9, so the system clock is 72MHz.

Look at the RCC registers.

Thanks… I am still finding my way around the ARM Processors Data Sheets…

Sorry for the Delay… I was trying to see if I could Read a Block, and then maybe attempt a Modify of the Block… ( that Code, not included here…)

Compiles, Download and Runs…

I made a few additions, in an effort to make sure the Code is running… I can at least see that the User Code is Invoked… (129 KB)