Posted on May 17, 2011 at 12:48hi d6,
the BL (''system memory'') is aliased to address 0 at reset if the BL is selected. the code could be compiled to run at address 0 or at its sys mem address (or a mixture of both). in the former case, invoking it from your code wouldn't work. excluding the mixture scenario, an easy way to distinguish between these two options is by taking a look at the value of the reset vector in the beginning of sys mem.
ST is not disclosing the code though we've asked, which is a pity. it could be used as a start to write your own BL or to better understand flash programming. it'd also reassure those of us who doubt its security. (unfortunately ST's secrecy on this matter has precisely the opposite effect on me.)
ST doesn't want you to use the BL from your code, as evidenced by the complete lack of info on how to do it. that's understandable; they want to be free to change the BL as they see fit. for instance, they might one day add more peripherals as sources of user code. reverse engineering the BL for security analysis or just for the heck of it would be a good move. but using the result of the analysis to invoke the BL from your production code would be a mistake IMHO.
> It seems like a waste of effort to write one's own code if the System Memory can be accessed.
that's why I say having the source code would be a good starting point for our work.
> If function calls were available, then they may be useful for making some flash operate as EE memory for data storage.
there's no read-while-write on the STM32 flash, so either the core would stall or you'd have to be running your code from RAM. few apps could tolerate not being responsive to interrupts during write operations. I believe there's sample code by ST to emulate EEPROM with flash.
> does anybody know how to read-out the system memory so it can be disassembled?
apparently you can simply dump it with your debugger or read it with your code. that's what I heard anyway.
