Porting to STM32L476Discovery/LimiFrog

Discussion and questions about boards that can run MicroPython but don't have a dedicated forum.
Target audience: Everyone interested in running MicroPython on other hardware.
User avatar
badi
Posts: 51
Joined: Mon Aug 10, 2015 2:18 pm
Location: Bern, Switzerland

Re: Porting to STM32L476Discovery/LimiFrog

Post by badi » Sat Apr 02, 2016 1:46 pm

If you are using stlink from https://github.com/texane/stlink: There is a bug in eraseing block 0 of the second bank which I fixed and created a pull request (https://github.com/texane/stlink/pull/388). (see my repo: https://github.com/tobbad/stlink).
badi

User avatar
badi
Posts: 51
Joined: Mon Aug 10, 2015 2:18 pm
Location: Bern, Switzerland

Re: Porting to STM32L476Discovery/LimiFrog

Post by badi » Sat Apr 02, 2016 3:05 pm

Is already merged by texane :-)
badi

User avatar
badi
Posts: 51
Joined: Mon Aug 10, 2015 2:18 pm
Location: Bern, Switzerland

Re: Porting to STM32L476Discovery/LimiFrog

Post by badi » Tue Apr 05, 2016 8:19 am

I wrote some very simple drivers for the sensors on limifrog board which are available here:
https://github.com/tobbad/limifrog
I maybe convert them to a more micropythonic style.

There is very simple support for the LCD (see seps525.py) which can be instantiated with:

Code: Select all

from limifrog import limifrog
from SEPS525 import LimiFrogDisplay

b = limifrog()
disp = LimiFrogDisplay(b)
then you can switch the display on `disp.on()` and fill some area `disp.fill(80, 160,0,100,0x00FF)`. To speed up the code I pre allocate the buffer and use micropython.viper to fill a memory area. Further the SPI transfer is done at 80 MHz. The speed is awesome :D

There is a main.py in the repo to demonstrate the LCD code.
badi

bobricius
Posts: 14
Joined: Sat Jul 30, 2016 11:07 pm

Re: Porting to STM32L476Discovery/LimiFrog

Post by bobricius » Sat Jul 30, 2016 11:12 pm

Hi I have try compile micropython for STM32L476 for my nucleo board with enabled DAC but I get this error
I read here that Dac is working, please can anybody help?


dac.c: In function 'pyb_dac_deinit':
dac.c:255:36: error: 'DAC_CR_BOFF1' undeclared (first use in this function)
DAC_Handle.Instance->CR |= DAC_CR_BOFF1;
^
dac.c:255:36: note: each undeclared identifier is reported only once for each function it appears in
dac.c:258:36: error: 'DAC_CR_BOFF2' undeclared (first use in this function)
DAC_Handle.Instance->CR |= DAC_CR_BOFF2;
^
../py/mkrules.mk:47: recipe for target 'build-LIMIFROG/dac.o' failed
make: *** [build-LIMIFROG/dac.o] Error 1

bobricius
Posts: 14
Joined: Sat Jul 30, 2016 11:07 pm

Re: Porting to STM32L476Discovery/LimiFrog

Post by bobricius » Sat Jul 30, 2016 11:42 pm

Hi, Is possible increase mass storage flash disk size to maximum? MCU have 1Mb flash but python board show only 100kb I read that it is not posible no F405 but on L476 ???

User avatar
dhylands
Posts: 3385
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Porting to STM32L476Discovery/LimiFrog

Post by dhylands » Sun Jul 31, 2016 12:21 am

On the L476 you should be able to increase the storage size by changing some of the constants in storage.c:
https://github.com/micropython/micropyt ... .c#L92-L93

The SMT32L476DISC board has a STM32L476VG which has 1 Mb of flash.

So if you put the start of the filesystem around 512K (i.e. set FLASH_MEM_SEG1_START_ADDR to 0x08080000) and set FLASH_MEM_SEG1_NUM_BLOCKS to 1024 (each block is 512 bytes, so this would map to 512K) then you should get a 512K flash drive.

Note that the above is untested.

The LimiFrog only has 512K flash, so you wouldn't be able to use that technique.

bobricius
Posts: 14
Joined: Sat Jul 30, 2016 11:07 pm

Re: Porting to STM32L476Discovery/LimiFrog

Post by bobricius » Sun Jul 31, 2016 9:52 am

Thanks. And I read that problem with low flash size is because F405 have many 128kb flash blocks. Do you think that L476 not have this problem ?

Can you help my with compilation with DAC enabled? I want create small sound fx player with sounds stored on internal flash.

bobricius
Posts: 14
Joined: Sat Jul 30, 2016 11:07 pm

Re: Porting to STM32L476Discovery/LimiFrog

Post by bobricius » Mon Aug 01, 2016 8:17 pm

dhylands: Thanks very much. It is working. I have 512KB. Do you think that is possible get more memory? ...700 or more

User avatar
dhylands
Posts: 3385
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Porting to STM32L476Discovery/LimiFrog

Post by dhylands » Tue Aug 02, 2016 1:33 am

MicroPython itself takes about 307K (that's for the STM32L476DISC image built using the latest source).

storage.c allows the filesystem flash to be split into 2 segments.

So you could leave the definitions for FLASH_MEM_SEG1_START_ADDR and FLASH_MEM_SEG1_NUM_BLOCKS as they were and then add definitions for FLASH_MEM_SEG2_START_ADDR and FLASH_MEM_SEG2_NUM_BLOCKS.

The tricky bit is figuring out where FLASH_MEM_SEG2_START_ADDR should go. If you run:

Code: Select all

$ objdump -h --section=.text build-STM32L476DISC/firmware.elf

build-STM32L476DISC/firmware.elf:     file format elf32-little

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  1 .text         00045dc4  08020000  08020000  00020000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
then we can see that the firmware goes to 0x8020000 + 0x45dc4 = 0x8065dc4. So you can start SEG2 on any 2K boundary higher than that, Keep in mind that as the firmware grows in size, you need to make sure that FLASH_MEM_SEG2_START_ADDR stays above the end of the firmware or your filesystem will wind up corrupting part of the firmware.

If you picked 0x8070000 that would give you about 40K of firmware expansion room, and would give you 576K + 126K = 702K for filesystem.

Also keep in mind that you need to reinitialize the filesystem anytime you change FLASH_MEM_SEG2_START_ADDR.

User avatar
badi
Posts: 51
Joined: Mon Aug 10, 2015 2:18 pm
Location: Bern, Switzerland

Re: Porting to STM32L476Discovery/LimiFrog

Post by badi » Sun Aug 07, 2016 1:48 pm

DAC Support:

@bobricius: As you can see the adding of the deinit function broke the code for STM32L4. The DAC_CR_BOFF1/2 is just defined for the stm32F4. As quick fix you can comment out the lines referencing DAC_CR_BOFFX (x=1,2). In my opinion these line should be conditional compiled only for F4 but not included on L4. Be aware that there were no extensive tests done for DAC functionality - so if you could give some feedback if DAC with this hacks works?

I may look into a proper solution.
badi

Post Reply