STM32L467DISC port not working?

[roland_vs]

Dear all,

I have compiled 1.8.7 and loaded using dfu-util on my pyboard10 (reference) and it is working as expected.

If I compile for the BOARD=STM32L476DISC it compiles fine and generates a file w/o a problem. I upload it using dfu-util in the same way (just make deploy) it is programmed onto the chip.
Rebooting shows a disk, and REPL is active, however it doesn't load any library whatsoever (like import pyb) but just restarts (prompt Micropython... >>>>). The file system is what you see with mbed, and not the usual boot/main...

So what could be the cause that it is not working?
What did I forget?

Roland

[shaoziyang]

STM32L4 serial has bug in dfu-util, you need download using other tools.

[roland_vs]

Dear @shaoziyang,

Thanks for the tip. With other tools you mean something like JTAG instead of the embedded boot loader of the chip?

Regards,

Roland

[shaoziyang]

Yes, I use ST-link to download.

[dhylands]

On the STM32F476DISC board, the mini-USB is connected to the STM32F103 (which is the stlink processor). The micro-USB is the one connected to the STM32L476.

So if you're using dfu-util, you need to use it withe the micro-usb plugged in. The mbed filesystem that you're seeing is the one that the STM32F103 presents on the mini-USB connector.

[roland_vs]

@dhylands

Dear Dave,

I used the micro-USB to do the dfu-util programming. The effect I see is that a "perfectly" compiled mpy using the BOARD=STM32L476DISC is not working. I cannot see the internal Flash, the Flash on the discovery board.

I have REPL access, but after for instance import pub, dir(pub) or whatever does not work, it seems to reboot.

[dhylands]

I just flashed mine, and there is something a bit wonky. I got the filesystem shown, but it showed on the host as a 17 Mb filesystem, which is obviously wrong.

The filesystem also only had boot.py on it. No main.py or other files that normally show up. It also had a label of 2821-0000 rather than PYBFLASH.

So I think that the filesystem problem needs to get fixed, since that could cause who knows what type of problems.

[roland_vs]

@dhylands

I found out where the problem is.

I checked out the /stmhal/storage.c. The addition for the STM32L476 has a nice way of defining two externals from were two pointers are derived that sets the start and the end of the allocated Flash storage.

As this is the only real difference compared to the other chips I changed it by hard coding the start and blocks available. As a result it works .

Code: Select all

// The STM32L476 doesn't have CCRAM, so we use the 32K SRAM2 for this.
#define CACHE_MEM_START_ADDR (0x10000000)       // SRAM2 data RAM, 32k
#define FLASH_SECTOR_SIZE_MAX (0x00800)         // 2k max
//#define FLASH_MEM_SEG1_START_ADDR ((long)&_flash_fs_start)
//#define FLASH_MEM_SEG1_NUM_BLOCKS ((&_flash_fs_end - &_flash_fs_start) / 512)

#define FLASH_MEM_SEG1_START_ADDR (0x08080000)
#define FLASH_MEM_SEG1_NUM_BLOCKS (1024)

Should I raise an issue or do you take care of it?

BTW: the initial method with the two variables sorts of breaks the way it is done for all other STM boards.

[marfis]

It's kind of odd. In mpconfigboard.h, there is MICROPY_HW_SPIFLASH_SIZE_BITS defined (probably to activate the external SPI flash).

This in turns activates a compiler switch within storage.c (USE_INTERNAL = 0). So your code snippet shouldn't make a difference on the outcome (since it's not active). Be aware of all the compiler switches there, it's not very transparent...

As I see it, if USE_INTERNAL is set to 0, then the internal flash file system is not used. It tries to use the external flash chip instead. Looking at the schematic, it's a Quad Spi flash chip so it probably needs special initialisation the way it is wired on the board. Maybe this chip has never worked properly under micro python?

On the limifrog HW, there is a similar setup with a Quad SPI flash chip - but in their mpconfigboard.h file there is no MICROPY_HW_SPIFLASH_SIZE_BITS definded (and the limifrog fw is working on my desk - however as mentioned without the external SPI flash).

So to summarize: Did you try to comment out MICROPY_HW_SPIFLASH_SIZE_BITS?

[roland_vs]

@marfis

Those many #defines do not always help readability. I will check your remark.

The external Flash on the 476DISC board seems to be initialised the right way for use with pyb.Flash(), but not as an extension to the memory space of the L476 after first reading.

I will look into this a little more... For now I'm fine as I can order my PCB with the L476 knowing that the current version of mpy will work on my board too...

Micropython is a GREAT piece of software!! I love it.