Forum : ARM
Original Post
Post Information | Post |
---|---|
June 14, 2011 - 5:57pm
|
We are working with another company to develop applications for a mutual Customer. During the development phase both companies want to separately put their code in read protected areas of Flash. An older version of Ride 7 allows this, however the latest version refuses to write to a non blank flash. Is there a work around? or am I doing something wrong? |
Hi,
I am surprised that this would work with an older version because read protection, even partial, usually prevents any debugging. But of course this depends on the target CPU, not on the tool.
To tell you more we will need to know which target device you are using (the complete name that you selected in the software), and the previous and new versions of the kits you are using (both Ride7 and RKit-XXX), and also how you were configuring the project for successfuly debugging with some read protection ON...
Best Regards,
Vincent
Hi Vincent
Thanks for your quick reply. We are using the STM32F103xxxx family of processors. The Ride 7 & RKIT versions are:
1. Ride 7 version 7.14.0001 with R-Kit ARM version 1.13.0810 (Allows multiple writes to Flash without erasing)
2. Ride 7 version 7.30.10.0159 with Patch 7.30.10.0169 R-Kit ARM version 1.26.10.0130
We are not too worried about debug since the interface between the two programs is just a math calculation with the result written to a preassigned memory location. We tested the passing of data by using two processors and sending the data over the SPI bus.
Any ideas will be greatly appreciated. It's actually the other company's problem but I'm just trying to be a bit proactive.
Thanks
Jack
Hi,
I would need to know which interface you are using (Ride, RFlasher or Cortex_pgm) and which commands you send to it for the 'second' prog.
Also, please clarify which kind of protection is ON, how you set it and how you check that it has been set? According to the STM32 doc (flash prog spec rev 8 pages 18-19), the hardware should not allow to modify the flash (except mass-erase) if it is read-protected. And these STM32F1xxx do not allow to read-protect partially; you can write-protect partialy, but the read-protect is "all or none". So the old version should not be able to do what you describe. It's not just about skipping the blank-check!
Best Regards,
Vincent
Thanks Vincent
Looks like we didn't check multi-write with read protect on.
Jack
Thanks Vincent
Looks like we didn't check multi-write with read protect on.
Jack