STM32L4 Core

Cores are the underlying magic that make the Arduino API possible
User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: STM32L4 Core

Post by GrumpyOldPizza » Tue Jul 19, 2016 11:42 am

inaba_nl wrote:no worries, just make sure you don't overwork yourself :)


also, i have put this on a github page about stm32 external flash storage (just not sure if it'll work)

Code: Select all

in the linker script there needs to be:

EXTFLASH (rw) : ORIGIN = 0x<start address>, LENGTH = 0x<length>

in the MEMORY section, and the SECTIONS needs to have:

.external_flash : { *(.External_Flash*); } > EXTFLASH

now we can start to have fun with adding code to the qspi flash.
to make it easy, use this define in the sketch:

#define EXTERNAL_MEM __attribute__((section("External_Flash")))

and usage can look like this:

EXTERNAL_MEM void external_loop() 
{ 
  while (1) 
  {
    //blink led forever 
    digitalWrite(13,LOW); 
    delay(500); 
    digitalWrite(13,HIGH); 
    delay(500); 
  } 
}
uThe QSPI flash is setup as a FAT file system, not as a flash extender. There are numerous reasons to do so. If the normal 512k flash runs out, one could always ask for a 1MB STM32L476 instead.

User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: STM32L4 Core

Post by GrumpyOldPizza » Tue Jul 19, 2016 11:48 am

Rick Kimball wrote:
inaba_nl wrote:.. also, i can barely wait till a rtos is supported (my preference: FreeRTOS) ..
I know it isn't true multi-tasking, however have you looked at the Scheduler library that works with the DUE and Zero? It provides cooperative multi-tasking. Your task runs to completion as long as you don't yield. I've tried it and it seems to work OK for trivial things. I haven't tried on anything substantial.
I have not looked into the "Scheduler" library at all. To be quite open there, the USB/MSC logic really needs to be in a separate task to not block other things. Not a biggy for the QSPI SFLASH, but an SDCARD via SPI/SDIO can block things quite a bit.

A project from an end-user here has a FAT logging requirement. The latency when a SDCARD decides to do garbage collection cannot be compensated for, unless you have a real preemptive multi tasking system.
Last edited by GrumpyOldPizza on Tue Jul 19, 2016 11:56 am, edited 1 time in total.

User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: STM32L4 Core

Post by GrumpyOldPizza » Tue Jul 19, 2016 11:52 am

rajdarge wrote:so I just bought a few of these from tindie.
I was expecting the super-capacitor pictured (I think thats what it was). Its no biggie that it wasn't, but it did take a little shine off the product.
Unfortunately I am one of those with "no clue" with a full time job in another area. So time is an obstacle.
However I am not daunted by my lack of time.
I would like to know if there is a forum somewhere devoted to this device, and a quickstart guide or something.
I have used a teensy 3.1 and 3.2 as I have a few of those. But I suppose I'd like to get into it and get my project done... without having to stuff around with trial an error.
Raj
The super capacitor is there, it might have changed size and packaging in the final revision though. There is sadly no quickstart guide. I am horribly at documentation, but thanx for bringing up the thought. Right now Dragonfly should be treated as being 100% compatible with Arduino Zero, and then as much compatible as possible with Arduino Uno.

User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: STM32L4 Core

Post by GrumpyOldPizza » Sun Jul 24, 2016 9:51 pm

0.0.14 just got uploaded. Fixes a VFAT LFN entry issue. DOSFS would generate illegal LFN entries ...

inaba_nl
Posts: 10
Joined: Thu Jul 14, 2016 9:07 pm

Re: STM32L4 Core

Post by inaba_nl » Mon Jul 25, 2016 6:33 pm

GrumpyOldPizza wrote: uThe QSPI flash is setup as a FAT file system, not as a flash extender. There are numerous reasons to do so. If the normal 512k flash runs out, one could always ask for a 1MB STM32L476 instead.
Let me be clear: my aplication will be way too huge for 1MB Flash, as i want to offload my apps on my qspi flash, as it can be programmed 100.000 times typical, 10times more than the internal flash, so ideal for reprogramming

anyone has an idea on how to archieve this without modding this stm32l4 core? :o

User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: STM32L4 Core

Post by GrumpyOldPizza » Mon Jul 25, 2016 7:13 pm

inaba_nl wrote:
GrumpyOldPizza wrote: uThe QSPI flash is setup as a FAT file system, not as a flash extender. There are numerous reasons to do so. If the normal 512k flash runs out, one could always ask for a 1MB STM32L476 instead.
Let me be clear: my aplication will be way too huge for 1MB Flash, as i want to offload my apps on my qspi flash, as it can be programmed 100.000 times typical, 10times more than the internal flash, so ideal for reprogramming

anyone has an idea on how to archieve this without modding this stm32l4 core? :o
It would not be that difficult to do in general. The stm32l4_qspi.c code could be changed to react to the address range; I suppose the WARs for the hardware erratas might be a tad tricky. Of course the internal file system would not work anymore.

There are a few issues that make it rather unattractive:

(1) How do you get the code into the QSPI FLASH ?

(2) The latency to get one single byte out of the SFLASH is 48 CPU clock cycles (one might be able to squish that down to 32, but there is a HW errata ...). The I/D cache is not active for that memory region. So executing code out of there is rather slow, so that at the end of the day using an overlay based scheme whereby you copy locally used segments of code into SRAM seems to be more efficient.

Ah, and not to forget the STM32L4 internal flash is speced for 100k erase cycles ... so from that point of view there is no big advantage.

inaba_nl
Posts: 10
Joined: Thu Jul 14, 2016 9:07 pm

Re: STM32L4 Core

Post by inaba_nl » Tue Jul 26, 2016 9:03 pm

1: custom ide with pointers to the api functions (the mcu core will have the mpu enabled to limit app's ram and access), with precompiled app flashing over usb raw hid, bluetooth or from a MicroSD(?).

2: so basically you're saying that the pebble smartwatches have much latency? i think not, they fit their purpose well, and use the same approach as i am trying to do. :P

here's a document on that for stm32 devices having that feature (including the stm32l4)
http://www.st.com/content/ccc/resource/ ... m=auto,100

User avatar
ahull
Posts: 1528
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: STM32L4 Core

Post by ahull » Tue Jul 26, 2016 10:08 pm

Could you use DMA to load blocks from the external flash? That way, your latency would be significantly reduced.
- Andy Hull -

User avatar
GrumpyOldPizza
Posts: 174
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: STM32L4 Core

Post by GrumpyOldPizza » Tue Jul 26, 2016 10:20 pm

inaba_nl wrote:2: so basically you're saying that the pebble smartwatches have much latency? i think not, they fit their purpose well, and use the same approach as i am trying to do. :P
I did not say any of that. I just stated that the latency (44 CPU clocks) is a big issue, so is the throughput (4 CPU clocks per byte, hence 8 CPU clocks per instruction). Since normal code does use quite often branches, that performance characteristic might not be the best. But by all means, the platform is open, the schematics are available and so is the datasheet for the Macronix SFLASH (I'd also recommend getting the SFDP spec from JEDEC, JDES216B).

inaba_nl
Posts: 10
Joined: Thu Jul 14, 2016 9:07 pm

Re: STM32L4 Core

Post by inaba_nl » Sat Sep 10, 2016 10:35 pm

sorry for the late response ^^;

you said the platform is open? if so, why not the bootloader? (just questioning)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest