STM32 target practicability question

Newcomers to Astrobe and Oberon are welcome to ask any beginner-level questions here
joeninety
Posts: 12
Joined: Sat Mar 19, 2016 10:36 pm

Re: STM32 target practicability question

Post by joeninety » Tue May 10, 2016 10:54 am

Hi.
I've been going through Astrobe sample code and documentation to try and understand it and see what I'll need to do for the STM32F103.
Here are my thoughts and questions comparing to the LPC1343.

Obviously I'll need an all new MCU module. Is anything in this referenced by the linker generated startup code?
I think I'll need an STM specific Traps module, as the STM SRAM is at 0x2000 0000, but otherwise I think this is good unchanged.
In the Main module I'll of course need to setup the PLL and clock dividers differently and in procedure Init the interrupt vector remapping to SRAM is different for the STM, as it appears the system control block is different, but apart from this if I implement suitable Serial.PutCh and Serial.GetCh I think it can be unchanged.

The STM32F103 has the primary addresses for flash and SRAM at 0x0800 0000 and 0x2000 0000 respectively, so the linker would need to allow for these. Also for the Maple Mini, the standard USB bootloader resides at 0x0800 0000 and loads user code to 0x0800 5000, but it would be nice to be able to use JTAG to load user code to 0x0800 0000 also.

For booting in the STM32F103 boot mode used by the Maple Mini the flash is aliased at 0x0000 0000 so the processor can find the startup vector table, but at least for the C libraries provided by LeafLabs the reset vector is set to a flash address in the 0x0800 0000 region, so as soon as the reset vector has first been loaded the flash primary address space, not the aliased one seems to be only one used.

In the target configuration I think I also need to choose a compatible heap start address.

Have I missed anything?

If not, would you be able to let me have a suitable command line linker and I'll give it a go?

Many thanks,
Joe

joeninety
Posts: 12
Joined: Sat Mar 19, 2016 10:36 pm

Re: STM32 target practicability question

Post by joeninety » Wed May 11, 2016 7:41 am

I realise I forgot to mention - though this may be normal or obvious - that the Maple Mini bootloader, although loading at 0x0800 5000 does not use a different flash image layout to what you would load with JTAG at 0x0800 0000, it is still expecting a vector table followed by code. After loading the image to 0x0800 5000, it sets the stack pointer to the contents of 0x0800 5000 and jumps to the address in 0x08005004.

cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: STM32 target practicability question

Post by cfbsoftware » Wed May 11, 2016 8:54 am

The linker generated options are referenced in the LinkOptions module which is referenced by MCU, not vice versa. This enables your Cortex-M3 application to make use at runtime of the parameters that were specified at link time.

You seem to have covered just about everything.

You will need our modified command-line linker before you can run anything on your STM board. I hope to be able to get it to you before the end of the month. In the meantime I recommend you experiment modifying the startup code with one of the NXP boards that we support (e.g. one that is most similar in capabilities to your target STM board). This will give you hands-on experience in a known working environment. It will also help you the future when you are trying to determine if a problem is a programming error or a platform-specific problem.

We will be testing the command-line linker with the STM Discovery kit for STM32L151/152:

https://www.element14.com/community/docs/DOC-67670

if you get one of these boards or already have one then you can use that as a 'reference' platform and we may be able to assist if you get stuck when attempting the porting exercise.

Once you have the command-line linker I recommended that you proceed one step at a time as outlined in the following steps. Each step will produce a program that you should run and test. You should verify that everything is working before moving on to the next step.

1. Implement a simple blinker using just two source code modules - your blinker code and an empty Main.mod file. The blinker code will use a simple loop to generate the delays e.g.

FOR i := 1 TO 400000 DO END;

will result in a suitable delay when using the default clock values.

2. Add PLL and Clock Control etc. to Main. Implement the delays by porting the Timer module and use it in your Blinker program to test that you have the clock rates set correctly.

3. Implement Serial. The modules In, Out, Put and Convert should compile and link without little or no modifications. Write a test program to send and receive single characters to the Astrobe terminal.

4. Test the example Info.mod

5. Implement Traps and ResData.

6. Add any peripherals to MCU that you intend to use.

7. Test the remaining general library modules and examples.

8. Port any hardware-specific library modules that you want to use.

You should then be ready to work on your own projects.

joeninety
Posts: 12
Joined: Sat Mar 19, 2016 10:36 pm

Re: STM32 target practicability question

Post by joeninety » Wed May 11, 2016 1:02 pm

That all sound great - thanks.

I have an Ezsbc2 already on order and can get hold of the STM Discovery kit quickly if I run into a problem.

cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: STM32 target practicability question

Post by cfbsoftware » Sun May 22, 2016 5:53 am

Progress report: All looking good so far. Rather than just modify the command-line compiler we have built the new capability into the Astrobe IDE as well.

The configuration files now include a 'Custom' selection which then enables fields that allow you to specify the Code and Data address ranges. Here is a preliminary screenshot:
Config.jpg
Config.jpg (41 KiB) Viewed 44891 times
We have used this to develop a LED blinking program for the STM32VLDISCOVERY (STM32F100) board. The source code is attached.

Unless any unexpected problems arise these features should be included in v6.0 of Astrobe for Cortex-M3 /M4. If you are a new or currently registered Professional user send an email to support at cfbsoftware.com if you are interested in reserving access to a preview release. We hope to have this available by the end of this month.
Attachments
STMBlinkerF100.zip
STMBlinker source
(742 Bytes) Downloaded 1130 times

joeninety
Posts: 12
Joined: Sat Mar 19, 2016 10:36 pm

Re: STM32 target practicability question

Post by joeninety » Tue May 24, 2016 2:33 pm

That looks very good and looks like it should cater for pretty much any M3 processor. Thank you.

Is the heap address range constrained to be within the data address range? I thought I remembered somewhere in your documentation that it isn't so that alternate on or off chip memory can be used for the heap.

My EZSBC2 has just arrived and I've started trying it, but as I'm running Windows 7 as a virtual machine under linux I seem to have come across some USB compatibility problems. I'm going to try NXP's LinuxNXPISP.sh script to do the loading, which I think should fix things.

joeninety
Posts: 12
Joined: Sat Mar 19, 2016 10:36 pm

Re: STM32 target practicability question

Post by joeninety » Tue May 24, 2016 7:59 pm

I've got the EZSBC2 Blinker example running now after correcting the errors in NXP's load script.

I've tried changing the speed and commenting out SetupPLL() in Main, after which everything blinks quite a bit more slowly, so I know what to expect now when starting with the STM32F103.

cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: STM32 target practicability question

Post by cfbsoftware » Tue May 24, 2016 10:37 pm

joeninety wrote:Is the heap address range constrained to be within the data address range?
The heap address range can be set to any directly accessible area of RAM.
There are some posts in this forum that give examples of its use:

Using the additional 16 / 32kB of RAM on LPC175x/6x MCUs

Using the additional 2kB of RAM on LPC131x / LPC134x MCUs

Note that the heap grows upwards from a low address to a high address whereas global data and the stack grow downwards from a high address to a low address.

joeninety
Posts: 12
Joined: Sat Mar 19, 2016 10:36 pm

Re: STM32 target practicability question

Post by joeninety » Thu Jun 30, 2016 12:01 pm

I now have code loading onto the maple mini using its built in USB DFU bootloader and have the led flashing and the clock and PLL initialised.

When I have the debug uart working too I'll post the files.

cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: STM32 target practicability question

Post by cfbsoftware » Thu Jun 30, 2016 12:14 pm

Great! I'm pleased to hear you are making good progress.

With the help of another Astrobe user we have successfully tested Astrobe for Cortex-M4 code on STM's Cortex-M7 MCUs. Consequently we are planning to add STM's Nucleo STM32F746ZG and Nucleo STM32F767ZI boards to our list of supported boards.

Post Reply