[chris250]

@support

I have found my issue. The example bootloader.props file in Step 14 on the example page is wrong (https://visualgdb.com/tutorials/tutorials/arm/bootloader/msbuild/).

Diffing between the github version and the one on the example page shows that the line:

CommandFormat="--rename-section .data=.bootldr < $@"

Should read:

CommandFormat="--rename-section .data=.bootldr $< $@"

 

• This reply was modified 3 years, 8 months ago by support. Reason: formatting

[chris250]

Hi all,

I am having this same issue. I am using the latest project. I have followed all the steps in this thread, but the bootloader.bin file is still being cleaned.

Is there anything else I can try?

Thanks

[chris250]

Hi,

Thank you for your reply and thank you for writing the guide. When I have finished this current project I will do some debugging and post any findings back here.

In the mean time, I have edited the linker file to say that the flash begins at 0x08040000 (where my application should be) and removed the embedded binary for the bootloader. That way I can still debug the application without openOCD erasing the sectors inbetween the bootloader and the application.

The OpenOCD guide does mention sector erasing, specifically:

Command: flash write_image [erase] [unlock] filename [offset] [type]
Write the image filename to the current target’s flash bank(s). Only loadable sections from the image are written. A relocation offset may be specified, in which case it is added to the base address for each section in the image. The file [type] can be specified explicitly as bin (binary), ihex (Intel hex), elf (ELF file), s19 (Motorola s19). mem, or builder. The relevant flash sectors will be erased prior to programming if the erase parameter is given. If unlock is provided, then the flash banks are unlocked before erase and program. The flash bank to use is inferred from the address of each image section.

Warning: Be careful using the erase flag when the flash is holding data you want to preserve. Portions of the flash outside those described in the image’s sections might be erased with no notice.

When a section of the image being written does not fill out all the sectors it uses, the unwritten parts of those sectors are necessarily also erased, because sectors can’t be partially erased.
Data stored in sector “holes” between image sections are also affected. For example, “flash write_image erase …” of an image with one byte at the beginning of a flash bank and one byte at the end erases the entire bank – not just the two sectors being written.
Also, when flash protection is important, you must re-apply it after it has been removed by the unlock flag.

This does say that the data inbetween sectors will be affected. I spent 10 minutes looking through the source for OpenOCD, and in openocd/src/flash/nor/core.c the following function is used to erase the flash:

/* Manipulate given flash region, selecting the bank according to target
 * and address. Maps an address range to a set of sectors, and issues
 * the callback() on that set ... e.g. to erase or unprotect its members.
 *
 * Parameter iterate_protect_blocks switches iteration of protect block
 * instead of erase sectors. If there is no protect blocks array, sectors
 * are used in iteration, so compatibility for old flash drivers is retained.
 *
 * The "pad_reason" parameter is a kind of boolean: when it's NULL, the
 * range must fit those sectors exactly. This is clearly safe; it can't
 * erase data which the caller said to leave alone, for example. If it's
 * non-NULL, rather than failing, extra data in the first and/or last
 * sectors will be added to the range, and that reason string is used when
 * warning about those additions.
 */
static int flash_iterate_address_range_inner(struct target *target,
 char *pad_reason, uint32_t addr, uint32_t length,
 bool iterate_protect_blocks,
 int (*callback)(struct flash_bank *bank, int first, int last))

This function basically starts at the first address and finds the sector range for the entire binary being programmed. In my case with the combined bootloader/application binary, that will span the sectors containing the EEPROM.

• This reply was modified 6 years, 1 month ago by chris250.
• This reply was modified 6 years, 1 month ago by chris250.

[chris250]

Hi,

I have modified my linker script and used arm-eabi-objdump -h <ELF file> to inspect the sections used.

It lists the following LMA addresses

• bootloader at 0x08000000
• .isr_vector, .text and other program sections at 0x08040000 +
• RAM objects to be loaded at boot at 0x08040d4b0 +

There is nothing in between the end of the bootloader code in the first sector (0x08000000), and the beginning of the program code (the ISR vector table) at 0x08040000.

Still, when I right click on the Visual Studio project and choose Program and Start Without Debugging I always see the following messages in the openocd output:

Info: Erasing FLASH: 0x08000000-0x08080000...
...
Info: Erasing FLASH: 0x08040000-0x08080000...

The project has got an embedded binary for its bootloader, which I created using the guide on this website. It is like openocd is treating the bootloader (0x08000000) plus the application (0x08040000) as one large blob that it needs to program, even though there is nothing in between the bootloader and the application.

Is there a way to configure this so that it doesn’t erase the sectors in between the bootloader and the application? That is where my EEPROM is located…

Thanks again for your help.

• This reply was modified 6 years, 1 month ago by chris250.

[chris250]

Hi Chaaalyy

The code I am running is using the internal flash to store some data. This data is spread across a couple of internal sectors. The data in these sectors (including the erase of a full sector) is done through using the HAL functions.

Hi Support,

Thanks for the reply. I am only erasing a single sector within the STM32 device. My research lead me to the STM32 ref manual flash section, that states:

Any attempt to read the Flash memory while it is being written or erased, causes the bus to
stall. Read operations are processed correctly once the program operation has completed.
This means that code or data fetches cannot be performed while a write/erase operation is
ongoing.

Could this affect the debugger?

Thanks in advance.

[chris250]

Hi,

Thanks for your help. It was exactly what you said – the semihosting stuff was expecting a debugger and so the code was waiting for it to attach.

Thanks

[chris250]

Hi

Thank you very much for you help. You are correct – it was the optimisation that was doing its job and changing the program flow. The default settings from IAR did not perform this modification and so the problem did not arise.

Your example lead me to do more reading on optimisation and its affects on programs.

I’ll be buying an Embedded license this week 🙂 Visual Studio – happy days!

[chris250]

Hi,

Thanks for the reply. I have tried many different builds including Release and changing the optimisation settings.

Raising the optimisation level makes the code unstable. The LED should flash with an even duty cycle but with optimisation turned on it does not. With maximum optimisation the LED does not flash at all.

The other issue here is that I need the debug version to run at a reasonable speed. Under IAR I can run with the debugger attached and drive the SD card at high speed with no errors. This isn’t possible under VisualGDB, and I haven’t enabled the USB section of the project yet either (that also runs at High Speed under IAR debug). I am concerned that the USB timing requirements will not be met when debugging with VisualGDB.

I am unaware of how VisualGDB performs its debugging. When debugging, should I expect to experience a speed reduction of up to 3 times slower?

I am grateful for any advice. I would really like to purchase VisualGDB (I am on trial at the moment) and use it within our company as I am a big fan of Visual Studio. The VisualGDB interface is a lot nicer to use than IAR and the Visual Studio editor is epic.

Thanks again for your help.

[chris250]

Hi,
I can’t seem to edit my post so I’ll add more information in this separate post.

My project includes interaction with a SD card. This stopped working under VisualGDB builds unless I slowed down the access rate considerably.

I have now stripped down my project so that all it does is flash an LED. This uses a local stack variable to count and toggle the output accordingly. The vast majority of the code is common between the IAR build and the VisualGDB build. The one exception is the startup file (startup_stm32f746xxx.c). I note the VisualGDB startup file does everything I would expect it to do (sysinit, clearing bss section, call to main, etc) and it looks good to me.

I have checked the contents of the RCC clocking registers following the initialisation and the results between IAR and VisualGDB are identical.

The VisualGDB build still runs a lot slower than the IAR build.

I have also tried editing my code to use the built-in BSP (not a stand-alone project). This also runs slow.

Any help is appreciated. Please let me know if you need any more information.

Thanks

[chris250]

Hi,

Thanks for your answer – I am using the toolchains shipped by yourselves now as they work straight away with no issues!

Thanks

[chris250]

3rd post in a row 🙂

Typical – I had been looking at this for a few hours and as soon as I post a question … I find the answer myself!!!

I was using the latest toolchain that I had downloaded from ARM. I am now using the Prebuilt GNU toolchain for arm-eabi downloaded from sysprogs and it works.

Thanks

[chris250]

Sorry to repost but I should add some more information for you…

I am using the latest ARM toolchain: 6-2017-q1-update. This is installed to c:\SysGCC\6_2017-q1-update.

The VisualGDB package manager does not display the GCC or GDB versions for this, but it does compile the project. It fails at the linking stage (sbrk).

Thanks

[chris250]

Hi,

I am also getting this error. I am currently using a 5.2r9 trial version and I am building for the STM32F746.

I have read the instruction above but I can not find the ‘provide default implementations for system calls’ checkbox anywhere. I have looked in various places, including: right click on Project, VisualGDB Project Properties.

I would be very grateful for some help.

Thanks

[Author]

Posts