[Solved]Finding errors in porting STM32L4R9IDISC for Micropython programming

[ndhuy]

Hi everyone,

I'm Huy. Currently I am working on the project of programming MicroPython on unsupported board, STM32L4R9IDISC to be specific.

I wrote 4 board definition files and 2 linker files. I also added "defined STM32L4R9xx" in dozens of places in the HAL library of L4.

Although i successfully "make BOARD=STM32L4R9IDISC", it did not work as other supported boards and I don't know what to do.

I already compared build log file and nothing different. I plan to use GDB tool ( i already installed and set up) to debug but it seems like that tool only debug .c file. I have .elf, .bin, .hex, .dfu file after "make".

So i want to ask:
1. Is there any other way to find errors and fix that?
2. In case the use of GDB is what should be done, how can I use that to debug in my case?

Thank you very much, Huy.

[jimmo]

This is the same board as from viewtopic.php?f=3&t=7239 ?

I wrote 4 board definition files and 2 linker files. I also added "defined STM32L4R9xx" in dozens of places in the HAL library of L4.

I'm surprised you had to modify the HAL (after updating stm32lib to the latest version) -- can you give an example of the sort of changes you had to make?

I already compared build log file and nothing different. I plan to use GDB tool ( i already installed and set up) to debug but it seems like that tool only debug .c file. I have .elf, .bin, .hex, .dfu file after "make".

The easiest way to use GDB is with an .elf file (and the .c files of course), and for embedded development you'll have to set up a target (i.e. the st-link). When you build with -g, the .elf file contains all the machine code and symbol references pointing to the C code. (The .bin/.hex/.dfu files are generated from the .elf and contain just what you need to put stuff in the right place in ROM on the device). But you should use GDB with the same .elf file that was used to generate the file that you flashed.

Here's an example using openocd to connect to the stlink. viewtopic.php?f=2&t=4293&p=39488

It's probably a good idea to get familiar with how to use GDB first, i.e. using a simple program that you can build and run locally on your PC.

Then I'd try using it on a board that already works -- do you have an other STM32 disco or nucleo boards that are already supported by MicroPython?

Then try on your L4R9 board.

[ndhuy]

This is the same board as from viewtopic.php?f=3&t=7239 ?

I'm surprised you had to modify the HAL (after updating stm32lib to the latest version) -- can you give an example of the sort of changes you had to make?

Oh, I just realize that i made some mistake in updating the latest version (1.14). I just updated and yeah, STM32L4R9 is already in this version. And now, i have to fix some errors again. Hope this work!!!

The easiest way to use GDB is with an .elf file (and the .c files of course), and for embedded development you'll have to set up a target (i.e. the st-link). When you build with -g, the .elf file contains all the machine code and symbol references pointing to the C code. (The .bin/.hex/.dfu files are generated from the .elf and contain just what you need to put stuff in the right place in ROM on the device). But you should use GDB with the same .elf file that was used to generate the file that you flashed.

Here's an example using openocd to connect to the stlink. viewtopic.php?f=2&t=4293&p=39488

It's probably a good idea to get familiar with how to use GDB first, i.e. using a simple program that you can build and run locally on your PC.

Then I'd try using it on a board that already works -- do you have an other STM32 disco or nucleo boards that are already supported by MicroPython?


Then try on your L4R9 board.

After fixing errors, i will give this a try if something wrong happen.

Thank you, Huy.