Can Crossload be used to set the Read Protection bits on the STM32F10x?

Comments

10 comments

  • Avatar
    Darcy Williams

    Hi guys, is this possible please?  We have a few decisions to make based upon what we can and can't do with Crossload.

    0
    Comment actions Permalink
  • Avatar
    Jon Elliott

    You could do this by either writing a simple RAM program to do it and downloading and running that with CrossLoad, or alternatively set up a disconnect script in your project (by modifying the "Target Script Options > Disconnect Script" property and your target script file) to carry out the operation when CrossLoad disconnects from the target after download.

    0
    Comment actions Permalink
  • Avatar
    Darcy Williams

    Having read through the TargetInterface help I can't see anything obvious to make that setting of ROP very easy. 

    I can see that the function TargetInterface.executeFunction(address, parameter, timeout), might allow me to achieve ROP *if* I was able to define the address/location that a function was stored in flash memory.  I could build that in to the main project and then call that routine from the disconnect script.

    I guess the other option is as you've suggested...  create a RAM project and then make our crossload batch file firstly upload the firmware, then upload the RAM program as a second stage...  and then somehow run that instead of the flash programme.  I can see how that would work but I'm not sure how to instruct CrossLoad to run that program from RAM after uploading it.

    0
    Comment actions Permalink
  • Avatar
    Jon Elliott

    Take a look at the STM32 target script (STM32_Target.js), I believe there are functions in there that do what you want.

    > I'm not sure how to instruct CrossLoad to run that program from RAM after uploading it.

    It should do that for you by default.

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    There are some words on the STM32 target script functions in the CPU support package documentation.

    0
    Comment actions Permalink
  • Avatar
    Darcy Williams

    Perhaps one of the problems is that we've been using the STM32F10x package...  let me double check that.  I have both those packages installed, but don't know which one our projects are using

    0
    Comment actions Permalink
  • Avatar
    Darcy Williams

    Okay, the problem appears to be that we're still using the STM32F10xpackages, which doesn't have any target script function bodies...  I'm guessing this package is no longer being supported by Rowley?  If so, is there an easy enough process for me to go through to convert our 8 projects over to the STM32 package? 

    It doesn't appear to be as easy as changing the target directories in the .hzp as I then bump in to a number of flash placement issues - since we have custom sections for a few of our devices.  The default flash placement files look pretty different... 

    Perhaps this question has been answered elsewhere?

    Thanks Michael & Jon.  At least this has identified why I'm encountering problems.

    0
    Comment actions Permalink
  • Avatar
    Wolfgang Hill

    Hi Darcy,

    I switched us over from the old STM32F10x package to the new STM32 one a couple of months ago. I don't know if I'd descibe it as an easy process, and there seemed to be no other way than to mule it through - but it only took me a couple of days, and we have a large solution spanning multiple projects (including libraries) - much like yourself I gather.

    The difficulty will really depend on your own architecture and software design, which of course I can't comment on. I would recommend on making the effort tho' as it was well worth it for us (even tho' we're not using the whole CMSIS Standard Peripheral Library thing). If you get stuck on a specific issue I'd be happy to tell you how we solved it, but you'll probably have no problem other than the time it might take.

    If you were using ST's firmware library, they have some notes about upgrading to the Standard Peripheral Library.

    Cheers,

    Wolf

    0
    Comment actions Permalink
  • Avatar
    Darcy Williams

    Hi Wolf,

    Cheers for that.  We're still using the 2.x peripheral library...  and we weren't planning to update that.  We've done so much testing with this release we're reluctant to change such a significant element of our product.

    I would think that I can change the package without being required to go with the v3.x peripheral library.

    I'd be interested to know what the differences are between the two packages

    Thanks

    Darcy

    0
    Comment actions Permalink
  • Avatar
    Wolfgang Hill

    A large chunk of the difference is in the way the access to STM32 registers and bits is done - the new package defines mapping structures in much the same way as the original ST firmware library. So if you're using ST's 2.x peripheral library, then that shouldn't actually affect you at all. We use our own hardware library (written in C++) and most of the pain for me was in the change to using Rowley's register mapping structures instead of our own ('cos of course they used different names to us ;-).

    We also use our own custom flash placement files, so didn't really notice any change there - except that the use of macros made placing a certain section easier.

    One thing that may catch you out is that some of the weak symbols for interrupt handlers have different names (in STM32_Startup.s).

    Good Luck!

    Wolf

    0
    Comment actions Permalink

Please sign in to leave a comment.