You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Alan Graves <ag...@deltacontrols.com> on 2017/03/06 23:16:39 UTC
New STM32F427xx port
I've been working on what I thought was a simple port to this architecture and have a problem with versions for the startup files. If I understand the STM architecture directories correctly I was expecting to simply swap out files used by the 'stm32f4discovery' package (ie. V1.4, dated 09-Jul-2012):
hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
with this one needed by my port:
startup_stm32f427xx.s
Unfortunately I found that the external CMSIS files located in this directory are dated much newer (ie. V2.5.1, 28-June-2016):
hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc/startup_stm32f407xx.s
Naturally I assumed that this would be a straight forward port since the microprocessor are very similar. Does anyone have the right version of the startup file that I can use?
Note that from what I can tell the include files being used by 'stm32f4discovery' port are being mixed with an older startup file version. Even though this appears to be working, I would suggest that the current STM bsp be brought up to date to use the newest CMSIS support as the global variables are quite a bit different. This would save others from running into similar confusion and porting problems.
ALan
Re: New STM32F427xx port
Posted by Fabio Utzig <ut...@utzig.org>.
On Mon, Mar 13, 2017, at 06:07 PM, Alan Graves wrote:
> Yes it might. I noticed that the CC3100 Wi-Fi module interface is using
> either a SPI connection or UART+RTS/CTS to communicate with the MCU. I
> believe the module is probably configured to use only one interface. A
> couple of years ago I looked at the Wi-Fi chip when I was developing with
> the TI TM4C123GH6PM (Cortext M4F chip) and a CC3100 Launchpad combination
> (no modules existed at time).
Yeah, the CC3200 is a Tiva + CC3100 module in one package AFAIK. No BLE
though.
>
> Hey just curious has anyone done anything with MyNewt on the Tiva C
> series chips?
Not that I know of.
RE: New STM32F427xx port
Posted by Alan Graves <ag...@deltacontrols.com>.
Yes it might. I noticed that the CC3100 Wi-Fi module interface is using either a SPI connection or UART+RTS/CTS to communicate with the MCU. I believe the module is probably configured to use only one interface. A couple of years ago I looked at the Wi-Fi chip when I was developing with the TI TM4C123GH6PM (Cortext M4F chip) and a CC3100 Launchpad combination (no modules existed at time).
Hey just curious has anyone done anything with MyNewt on the Tiva C series chips?
ALan
-----Original Message-----
From: Fabio Utzig [mailto:utzig@utzig.org]
Sent: Monday, March 13, 2017 11:30 AM
To: dev@mynewt.incubator.apache.org
Subject: Re: New STM32F427xx port
Hi Alan,
Interesting board, it has a CC3100 wifi chip which would be nice to have supported by Mynewt! :P
Looks like a good candidate for a BSP. The .NET Micro Framework compatibility can be ignored in our case.
Cheers,
Fabio Utzig
On Mon, Mar 13, 2017, at 02:45 PM, Alan Graves wrote:
> Hi Marko,
>
> I had a look around for STM32F427xx development boards and came across
> these ones from Adafruit:
>
> http://www.netduino.com/netduino3/
> http://ca.mouser.com/new/netduino/netduino-netduino-3/
>
> Not exactly the same version of the MCU used on the custom 'sensorhub'
> board, they are fairly close and might make a suitable open source
> target board for the port.
>
> BTW I don't think I've ever heard of the .NET Micro Framework!
> Although the GoBus ports and Arduino I/O header compatibility are not
> too bad an idea. :)
>
> ALan
>
>
> -----Original Message-----
> From: marko kiiskila [mailto:marko@runtime.io]
> Sent: Thursday, March 09, 2017 5:40 PM
> To: dev <de...@mynewt.incubator.apache.org>
> Subject: Re: New STM32F427xx port
>
> Hi Alan,
>
> it is hard to maintain the right caffeine balance.
>
> I was just starting to scratch my head thinking about what could be
> going on when you sent this message.
>
> Keep console open when bringing things up. asserts show up there, and
> if the system gets past os_init(), and you have console uart enabled,
> you’ll see output if (when) things do not go the right way (aka hard
> faults and unhandled interrupts).
>
> > On Mar 9, 2017, at 5:25 PM, Alan Graves <ag...@deltacontrols.com> wrote:
> >
> > Ignore that last message - I'm gonna choc it up to either too much or too little coffee.
> >
> > Reprogramming everything and starting fresh showed no weirdness...
> >
> > ALan
> >
> > -----Original Message-----
> > From: Alan Graves [mailto:agraves@deltacontrols.com]
> > Sent: Thursday, March 09, 2017 4:45 PM
> > To: dev@mynewt.incubator.apache.org
> > Subject: RE: New STM32F427xx port
> >
> > I have some odd behavior, but I'm sure someone will have an idea of what is happening. I've been debugging this port and things seemed to be running smoothly, so I detached the debugger and power cycled the board. Obviously I was expecting to see the board come up and start blinking a LED, which it does nicely when loaded under the debugger. Unfortunately, without the debugger the bootloader does not vector off to the 'blinky' application as I was expecting. I therefore reconnected the debugger and proceeded to debug the application. After doing a ^C I notice that the debugger shows that the mcu's PC is sitting at the default memory map which has a HardFault_Handler in place of the Reset_Handler. I'm not sure how things got there, so I actually trace through the entire boot up sequence by forcing a jump to the Reset_Handler of the bootloader. BTW this was very educational to do and I highly recommended it :) The bootloader successfully gets through to the final call of the hal_system_start() function, which tries to jump to the image, unfortunately the memory map isn't correct so the application never starts.
> >
> > I'm hoping this problem sounds familiar to someone?
> >
> > ALan
> >
> > -----Original Message-----
> > From: Alan Graves [mailto:agraves@deltacontrols.com]
> > Sent: Wednesday, March 08, 2017 5:23 PM
> > To: dev@mynewt.incubator.apache.org
> > Subject: RE: New STM32F427xx port
> >
> > Asserts are better than nothing in the low-level, but not exactly a graceful exit. I definitely have a better idea of what is going on behind the scenes now that I've struggled with this very basic port.
> >
> > BTW I have an idea of how much work is involved in a project of this magnitude and it's an enormous accomplishment. So nice job everyone on the MyNewt project.
> >
> > ALan
> >
> > -----Original Message-----
> > From: marko kiiskila [mailto:marko@runtime.io]
> > Sent: Wednesday, March 08, 2017 4:14 PM
> > To: dev <de...@mynewt.incubator.apache.org>
> > Subject: Re: New STM32F427xx port
> >
> > Cool, nice progress.
> >
> > I’ll comment more inline.
> >
> >> On Mar 8, 2017, at 4:00 PM, Alan Graves <ag...@deltacontrols.com> wrote:
> >>
> >> False alarm! The newt load and debug scripts are working now. I had an error in a .cfg file that was causing an openocd error...
> >>
> >> ALan
> >>
> >> -----Original Message-----
> >> From: Alan Graves [mailto:agraves@deltacontrols.com]
> >> Sent: Wednesday, March 08, 2017 3:12 PM
> >> To: dev@mynewt.incubator.apache.org
> >> Subject: RE: New STM32F427xx port
> >>
> >> Wow finally the OS is running, at least under a J-Link debugger, however I'm having issues getting a 'newt load xxx_blinky' to work or even get 'xxx_blinky' operating without using the debugger.
> >>
> >> Here is what I've had to do to get things kind of going:
> >> (1) I discovered that I can muck about with other tools, namely IAR EWARM (under Windows) or JLinkExe (under Linux), to erase the entire MCU Flash memory. This is very important when running 'slinky’!
> >
> > You can also do this with openocd. ‘mon stm32f2x mass_erase 0’ from gdb would do it.
> > Ill-named command, but that should do it.
> >
> >> (2) I can also run 'openocd' from a terminal to establish a J-Link debugger connection first because the 'newt load xxx_boot' scripts fail to startup the openocd. I can't figure those blasted scripts out!
> >> $ openocd -f /usr/share/openocd/scripts/interface/jlink.cfg -f openocd.cfg Open On-Chip Debugger 0.10.0+dev-00092-g77189db (2017-03-01-15:08) Licensed under GNU GPL v2 For bug reports, read
> >> http://openocd.org/doc/doxygen/bugs.html
> >> Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
> >> adapter speed: 2000 kHz
> >> adapter_nsrst_delay: 100
> >> jtag_ntrst_delay: 100
> >> none separate
> >> cortex_m reset_config sysresetreq
> >> Info : No device selected, using first device.
> >> Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46 Info : Hardware version: 8.00 Info : VTarget = 3.319 V Info : clock speed 2000 kHz Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4) Info : JTAG tap: stm32f4x.bs tap/device found: 0x06419041 (mfg: 0x020 (STMicroelectronics), part: 0x6419, ver: 0x0) Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints <snip> File jlink.cfg:
> >> interface jlink
> >> <eof>
> >> File openocd.cfg:
> >> set WORKAREASIZE 0x40000
> >> source [find target/stm32f4x.cfg]
> >> <eof>
> >> (3) Then using 'newt debug xxx_boot' in another terminal type 'load' to program the Flash and begin debugging or just exit.
> >> (4) Then repeat using 'newt debug xxx_blinky' or 'newt debug xxx_slinky', etc.
> >> Needless to say this is an inconvenient process!
> >>
> >> Some observations:
> >> (1) I noticed that I get an assert() message coming from the function log_reboot_pkg_init() which was traced to the fcb_init() function returning rc = -7 (to do with bad MAGIC). I figured out this is because the circular Flash boot log can't be initialized if there is anything other than FF's at Flash location 0x8004000 - hence the need to erase the entire chip.
> >
> > Yup. I’m thinking we should erase that area if it has unexpected data in it.
> > At the moment if fcb_init() backs out due to seeing unexpected magic in it, and log_reboot_pkg_init() asserts.
> >
> >> (2) Note by overriding slinky's default configuration to log reboots to flash shown below, I was able to get the console up and running ok:
> >> File syscfg.yml:
> >> # Package: apps/slinky
> >> syscfg.vals:
> >> # Log reboot messages to a flash circular buffer.
> >> REBOOT_LOG_FCB: 0
> >> LOG_FCB: 0
> >> <eof>
> >> (3) I'm assuming that the Flash memory mapping is probably correct. Actually this mapping originated from the existing STM32F407xx, which has up to 1M of on chip Flash so I believe the same memory map should work for 1M version of the STM32F427IG chip that I'm using.
> >
> > I suspect that’s correct. I’m assuming here that the flash sector boundaries are the same on this model are the same as they are on 407.
> >
> >> File bsp.yml file:
> >> bsp.flash_map:
> >> areas:
> >> # System areas.
> >> FLASH_AREA_BOOTLOADER:
> >> device: 0
> >> offset: 0x08000000
> >> size: 16kB
> >> FLASH_AREA_IMAGE_0:
> >> device: 0
> >> offset: 0x08020000
> >> size: 384kB
> >> FLASH_AREA_IMAGE_1:
> >> device: 0
> >> offset: 0x08080000
> >> size: 384kB
> >> FLASH_AREA_IMAGE_SCRATCH:
> >> device: 0
> >> offset: 0x080e0000
> >> size: 128kB
> >>
> >> # User areas.
> >> FLASH_AREA_REBOOT_LOG:
> >> user_id: 0
> >> device: 0
> >> offset: 0x08004000
> >> size: 16kB
> >> FLASH_AREA_NFFS:
> >> user_id: 1
> >> device: 0
> >> offset: 0x08008000
> >> size: 32kB
> >> <eof>
> >> BTW Does anyone know why there is a 64K hole above the NFFS Flash area (ie. 0x80010000-0x8001FFFF) that isn't accounted for?
> >
> > That is just unused by default. You can use it to stash logs, more config etc.
> >
> >> (4) The SRAM size is a bit bigger so I adjusted the SRAM_SIZE from 128K to 192K in the bsp.h file.
> >>
> >> Am I missing something else? Any suggestions are welcome.
> >
> > Linker scripts are the key for RAM size. I assume you meant define RAM_SIZE, not SRAM_SIZE?
> > This is used in hal_bsp to figure out the default memory areas to include in coredump, if ppl end up using those.
> >
> >>
> >> ALan
> >>
> >> -----Original Message-----
> >> From: Alan Graves [mailto:agraves@deltacontrols.com]
> >> Sent: Monday, March 06, 2017 5:29 PM
> >> To: dev@mynewt.incubator.apache.org
> >> Subject: RE: New STM32F427xx port
> >>
> >> Thx Fabio for those tips. I'll keep plugging away at it.
> >> ALan
> >>
> >> -----Original Message-----
> >> From: Fabio Utzig [mailto:utzig@utzig.org]
> >> Sent: Monday, March 06, 2017 4:42 PM
> >> To: dev@mynewt.incubator.apache.org
> >> Subject: Re: New STM32F427xx port
> >>
> >> Hi Alan,
> >>
> >> I recently created a port for the STM32F7xx, which is not complete due to some missing hal_ drivers, but I upgraded CMSIS to 4.3.0. PR is waiting to be merged:
> >>
> >> https://github.com/apache/incubator-mynewt-core/pull/179/
> >>
> >> And I used as base for the startup/etc files STM32Cube V1.6.0. My idea would be to upgrade all STM32Fx ports to that version, to at least have some tracking of what versions are being used, etc, otherwise everything is getting to be messy with lots of different ext files around.
> >>
> >> Anyway, at least two changes I remember having to do to the startup_*.s:
> >>
> >> 1) It jumps to "main" at the end of the Reset_Handler. You need to change it to jump to "_start".
> >> 2) There is already zeroing of the "bss" section, but you also need to add zeroing of "corebss".
> >>
> >> Of course the linker script also has to be updated accordingly (sections/labels that match).
> >>
> >> Cheers,
> >> Fabio Utzig
> >>
> >> On Mon, Mar 6, 2017, at 08:16 PM, Alan Graves wrote:
> >>> I've been working on what I thought was a simple port to this
> >>> architecture and have a problem with versions for the startup files.
> >>> If I understand the STM architecture directories correctly I was
> >>> expecting to simply swap out files used by the 'stm32f4discovery'
> >>> package (ie. V1.4, dated 09-Jul-2012):
> >>> hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
> >>> with this one needed by my port:
> >>> startup_stm32f427xx.s
> >>>
> >>> Unfortunately I found that the external CMSIS files located in
> >>> this directory are dated much newer (ie. V2.5.1, 28-June-2016):
> >>>
> >>> hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Sou
> >>> rc
> >>> e
> >>> /
> >>> Templates/gcc/startup_stm32f407xx.s
> >>>
> >>> Naturally I assumed that this would be a straight forward port
> >>> since the microprocessor are very similar. Does anyone have the
> >>> right version of the startup file that I can use?
> >>>
> >>> Note that from what I can tell the include files being used by
> >>> 'stm32f4discovery' port are being mixed with an older startup file
> >>> version. Even though this appears to be working, I would suggest
> >>> that the current STM bsp be brought up to date to use the newest
> >>> CMSIS support as the global variables are quite a bit different.
> >>> This would save others from running into similar confusion and porting problems.
> >>>
> >>> ALan
> >
>
Re: New STM32F427xx port
Posted by Fabio Utzig <ut...@utzig.org>.
Hi Alan,
Interesting board, it has a CC3100 wifi chip which would be nice to have
supported by Mynewt! :P
Looks like a good candidate for a BSP. The .NET Micro Framework
compatibility can be ignored in our case.
Cheers,
Fabio Utzig
On Mon, Mar 13, 2017, at 02:45 PM, Alan Graves wrote:
> Hi Marko,
>
> I had a look around for STM32F427xx development boards and came across
> these ones from Adafruit:
>
> http://www.netduino.com/netduino3/
> http://ca.mouser.com/new/netduino/netduino-netduino-3/
>
> Not exactly the same version of the MCU used on the custom 'sensorhub'
> board, they are fairly close and might make a suitable open source target
> board for the port.
>
> BTW I don't think I've ever heard of the .NET Micro Framework! Although
> the GoBus ports and Arduino I/O header compatibility are not too bad an
> idea. :)
>
> ALan
>
>
> -----Original Message-----
> From: marko kiiskila [mailto:marko@runtime.io]
> Sent: Thursday, March 09, 2017 5:40 PM
> To: dev <de...@mynewt.incubator.apache.org>
> Subject: Re: New STM32F427xx port
>
> Hi Alan,
>
> it is hard to maintain the right caffeine balance.
>
> I was just starting to scratch my head thinking about what could be going
> on when you sent this message.
>
> Keep console open when bringing things up. asserts show up there, and if
> the system gets past os_init(), and you have console uart enabled, you’ll
> see output if (when) things do not go the right way (aka hard faults and
> unhandled interrupts).
>
> > On Mar 9, 2017, at 5:25 PM, Alan Graves <ag...@deltacontrols.com> wrote:
> >
> > Ignore that last message - I'm gonna choc it up to either too much or too little coffee.
> >
> > Reprogramming everything and starting fresh showed no weirdness...
> >
> > ALan
> >
> > -----Original Message-----
> > From: Alan Graves [mailto:agraves@deltacontrols.com]
> > Sent: Thursday, March 09, 2017 4:45 PM
> > To: dev@mynewt.incubator.apache.org
> > Subject: RE: New STM32F427xx port
> >
> > I have some odd behavior, but I'm sure someone will have an idea of what is happening. I've been debugging this port and things seemed to be running smoothly, so I detached the debugger and power cycled the board. Obviously I was expecting to see the board come up and start blinking a LED, which it does nicely when loaded under the debugger. Unfortunately, without the debugger the bootloader does not vector off to the 'blinky' application as I was expecting. I therefore reconnected the debugger and proceeded to debug the application. After doing a ^C I notice that the debugger shows that the mcu's PC is sitting at the default memory map which has a HardFault_Handler in place of the Reset_Handler. I'm not sure how things got there, so I actually trace through the entire boot up sequence by forcing a jump to the Reset_Handler of the bootloader. BTW this was very educational to do and I highly recommended it :) The bootloader successfully gets through to the final call of the hal_system_start() function, which tries to jump to the image, unfortunately the memory map isn't correct so the application never starts.
> >
> > I'm hoping this problem sounds familiar to someone?
> >
> > ALan
> >
> > -----Original Message-----
> > From: Alan Graves [mailto:agraves@deltacontrols.com]
> > Sent: Wednesday, March 08, 2017 5:23 PM
> > To: dev@mynewt.incubator.apache.org
> > Subject: RE: New STM32F427xx port
> >
> > Asserts are better than nothing in the low-level, but not exactly a graceful exit. I definitely have a better idea of what is going on behind the scenes now that I've struggled with this very basic port.
> >
> > BTW I have an idea of how much work is involved in a project of this magnitude and it's an enormous accomplishment. So nice job everyone on the MyNewt project.
> >
> > ALan
> >
> > -----Original Message-----
> > From: marko kiiskila [mailto:marko@runtime.io]
> > Sent: Wednesday, March 08, 2017 4:14 PM
> > To: dev <de...@mynewt.incubator.apache.org>
> > Subject: Re: New STM32F427xx port
> >
> > Cool, nice progress.
> >
> > I’ll comment more inline.
> >
> >> On Mar 8, 2017, at 4:00 PM, Alan Graves <ag...@deltacontrols.com> wrote:
> >>
> >> False alarm! The newt load and debug scripts are working now. I had an error in a .cfg file that was causing an openocd error...
> >>
> >> ALan
> >>
> >> -----Original Message-----
> >> From: Alan Graves [mailto:agraves@deltacontrols.com]
> >> Sent: Wednesday, March 08, 2017 3:12 PM
> >> To: dev@mynewt.incubator.apache.org
> >> Subject: RE: New STM32F427xx port
> >>
> >> Wow finally the OS is running, at least under a J-Link debugger, however I'm having issues getting a 'newt load xxx_blinky' to work or even get 'xxx_blinky' operating without using the debugger.
> >>
> >> Here is what I've had to do to get things kind of going:
> >> (1) I discovered that I can muck about with other tools, namely IAR EWARM (under Windows) or JLinkExe (under Linux), to erase the entire MCU Flash memory. This is very important when running 'slinky’!
> >
> > You can also do this with openocd. ‘mon stm32f2x mass_erase 0’ from gdb would do it.
> > Ill-named command, but that should do it.
> >
> >> (2) I can also run 'openocd' from a terminal to establish a J-Link debugger connection first because the 'newt load xxx_boot' scripts fail to startup the openocd. I can't figure those blasted scripts out!
> >> $ openocd -f /usr/share/openocd/scripts/interface/jlink.cfg -f openocd.cfg Open On-Chip Debugger 0.10.0+dev-00092-g77189db (2017-03-01-15:08) Licensed under GNU GPL v2 For bug reports, read
> >> http://openocd.org/doc/doxygen/bugs.html
> >> Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
> >> adapter speed: 2000 kHz
> >> adapter_nsrst_delay: 100
> >> jtag_ntrst_delay: 100
> >> none separate
> >> cortex_m reset_config sysresetreq
> >> Info : No device selected, using first device.
> >> Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46 Info : Hardware version: 8.00 Info : VTarget = 3.319 V Info : clock speed 2000 kHz Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4) Info : JTAG tap: stm32f4x.bs tap/device found: 0x06419041 (mfg: 0x020 (STMicroelectronics), part: 0x6419, ver: 0x0) Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints <snip> File jlink.cfg:
> >> interface jlink
> >> <eof>
> >> File openocd.cfg:
> >> set WORKAREASIZE 0x40000
> >> source [find target/stm32f4x.cfg]
> >> <eof>
> >> (3) Then using 'newt debug xxx_boot' in another terminal type 'load' to program the Flash and begin debugging or just exit.
> >> (4) Then repeat using 'newt debug xxx_blinky' or 'newt debug xxx_slinky', etc.
> >> Needless to say this is an inconvenient process!
> >>
> >> Some observations:
> >> (1) I noticed that I get an assert() message coming from the function log_reboot_pkg_init() which was traced to the fcb_init() function returning rc = -7 (to do with bad MAGIC). I figured out this is because the circular Flash boot log can't be initialized if there is anything other than FF's at Flash location 0x8004000 - hence the need to erase the entire chip.
> >
> > Yup. I’m thinking we should erase that area if it has unexpected data in it.
> > At the moment if fcb_init() backs out due to seeing unexpected magic in it, and log_reboot_pkg_init() asserts.
> >
> >> (2) Note by overriding slinky's default configuration to log reboots to flash shown below, I was able to get the console up and running ok:
> >> File syscfg.yml:
> >> # Package: apps/slinky
> >> syscfg.vals:
> >> # Log reboot messages to a flash circular buffer.
> >> REBOOT_LOG_FCB: 0
> >> LOG_FCB: 0
> >> <eof>
> >> (3) I'm assuming that the Flash memory mapping is probably correct. Actually this mapping originated from the existing STM32F407xx, which has up to 1M of on chip Flash so I believe the same memory map should work for 1M version of the STM32F427IG chip that I'm using.
> >
> > I suspect that’s correct. I’m assuming here that the flash sector boundaries are the same on this model are the same as they are on 407.
> >
> >> File bsp.yml file:
> >> bsp.flash_map:
> >> areas:
> >> # System areas.
> >> FLASH_AREA_BOOTLOADER:
> >> device: 0
> >> offset: 0x08000000
> >> size: 16kB
> >> FLASH_AREA_IMAGE_0:
> >> device: 0
> >> offset: 0x08020000
> >> size: 384kB
> >> FLASH_AREA_IMAGE_1:
> >> device: 0
> >> offset: 0x08080000
> >> size: 384kB
> >> FLASH_AREA_IMAGE_SCRATCH:
> >> device: 0
> >> offset: 0x080e0000
> >> size: 128kB
> >>
> >> # User areas.
> >> FLASH_AREA_REBOOT_LOG:
> >> user_id: 0
> >> device: 0
> >> offset: 0x08004000
> >> size: 16kB
> >> FLASH_AREA_NFFS:
> >> user_id: 1
> >> device: 0
> >> offset: 0x08008000
> >> size: 32kB
> >> <eof>
> >> BTW Does anyone know why there is a 64K hole above the NFFS Flash area (ie. 0x80010000-0x8001FFFF) that isn't accounted for?
> >
> > That is just unused by default. You can use it to stash logs, more config etc.
> >
> >> (4) The SRAM size is a bit bigger so I adjusted the SRAM_SIZE from 128K to 192K in the bsp.h file.
> >>
> >> Am I missing something else? Any suggestions are welcome.
> >
> > Linker scripts are the key for RAM size. I assume you meant define RAM_SIZE, not SRAM_SIZE?
> > This is used in hal_bsp to figure out the default memory areas to include in coredump, if ppl end up using those.
> >
> >>
> >> ALan
> >>
> >> -----Original Message-----
> >> From: Alan Graves [mailto:agraves@deltacontrols.com]
> >> Sent: Monday, March 06, 2017 5:29 PM
> >> To: dev@mynewt.incubator.apache.org
> >> Subject: RE: New STM32F427xx port
> >>
> >> Thx Fabio for those tips. I'll keep plugging away at it.
> >> ALan
> >>
> >> -----Original Message-----
> >> From: Fabio Utzig [mailto:utzig@utzig.org]
> >> Sent: Monday, March 06, 2017 4:42 PM
> >> To: dev@mynewt.incubator.apache.org
> >> Subject: Re: New STM32F427xx port
> >>
> >> Hi Alan,
> >>
> >> I recently created a port for the STM32F7xx, which is not complete due to some missing hal_ drivers, but I upgraded CMSIS to 4.3.0. PR is waiting to be merged:
> >>
> >> https://github.com/apache/incubator-mynewt-core/pull/179/
> >>
> >> And I used as base for the startup/etc files STM32Cube V1.6.0. My idea would be to upgrade all STM32Fx ports to that version, to at least have some tracking of what versions are being used, etc, otherwise everything is getting to be messy with lots of different ext files around.
> >>
> >> Anyway, at least two changes I remember having to do to the startup_*.s:
> >>
> >> 1) It jumps to "main" at the end of the Reset_Handler. You need to change it to jump to "_start".
> >> 2) There is already zeroing of the "bss" section, but you also need to add zeroing of "corebss".
> >>
> >> Of course the linker script also has to be updated accordingly (sections/labels that match).
> >>
> >> Cheers,
> >> Fabio Utzig
> >>
> >> On Mon, Mar 6, 2017, at 08:16 PM, Alan Graves wrote:
> >>> I've been working on what I thought was a simple port to this
> >>> architecture and have a problem with versions for the startup files.
> >>> If I understand the STM architecture directories correctly I was
> >>> expecting to simply swap out files used by the 'stm32f4discovery'
> >>> package (ie. V1.4, dated 09-Jul-2012):
> >>> hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
> >>> with this one needed by my port:
> >>> startup_stm32f427xx.s
> >>>
> >>> Unfortunately I found that the external CMSIS files located in this
> >>> directory are dated much newer (ie. V2.5.1, 28-June-2016):
> >>>
> >>> hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Sourc
> >>> e
> >>> /
> >>> Templates/gcc/startup_stm32f407xx.s
> >>>
> >>> Naturally I assumed that this would be a straight forward port since
> >>> the microprocessor are very similar. Does anyone have the right
> >>> version of the startup file that I can use?
> >>>
> >>> Note that from what I can tell the include files being used by
> >>> 'stm32f4discovery' port are being mixed with an older startup file
> >>> version. Even though this appears to be working, I would suggest
> >>> that the current STM bsp be brought up to date to use the newest
> >>> CMSIS support as the global variables are quite a bit different.
> >>> This would save others from running into similar confusion and porting problems.
> >>>
> >>> ALan
> >
>
RE: New STM32F427xx port
Posted by Alan Graves <ag...@deltacontrols.com>.
Hi Marko,
I had a look around for STM32F427xx development boards and came across these ones from Adafruit:
http://www.netduino.com/netduino3/
http://ca.mouser.com/new/netduino/netduino-netduino-3/
Not exactly the same version of the MCU used on the custom 'sensorhub' board, they are fairly close and might make a suitable open source target board for the port.
BTW I don't think I've ever heard of the .NET Micro Framework! Although the GoBus ports and Arduino I/O header compatibility are not too bad an idea. :)
ALan
-----Original Message-----
From: marko kiiskila [mailto:marko@runtime.io]
Sent: Thursday, March 09, 2017 5:40 PM
To: dev <de...@mynewt.incubator.apache.org>
Subject: Re: New STM32F427xx port
Hi Alan,
it is hard to maintain the right caffeine balance.
I was just starting to scratch my head thinking about what could be going on when you sent this message.
Keep console open when bringing things up. asserts show up there, and if the system gets past os_init(), and you have console uart enabled, you’ll see output if (when) things do not go the right way (aka hard faults and unhandled interrupts).
> On Mar 9, 2017, at 5:25 PM, Alan Graves <ag...@deltacontrols.com> wrote:
>
> Ignore that last message - I'm gonna choc it up to either too much or too little coffee.
>
> Reprogramming everything and starting fresh showed no weirdness...
>
> ALan
>
> -----Original Message-----
> From: Alan Graves [mailto:agraves@deltacontrols.com]
> Sent: Thursday, March 09, 2017 4:45 PM
> To: dev@mynewt.incubator.apache.org
> Subject: RE: New STM32F427xx port
>
> I have some odd behavior, but I'm sure someone will have an idea of what is happening. I've been debugging this port and things seemed to be running smoothly, so I detached the debugger and power cycled the board. Obviously I was expecting to see the board come up and start blinking a LED, which it does nicely when loaded under the debugger. Unfortunately, without the debugger the bootloader does not vector off to the 'blinky' application as I was expecting. I therefore reconnected the debugger and proceeded to debug the application. After doing a ^C I notice that the debugger shows that the mcu's PC is sitting at the default memory map which has a HardFault_Handler in place of the Reset_Handler. I'm not sure how things got there, so I actually trace through the entire boot up sequence by forcing a jump to the Reset_Handler of the bootloader. BTW this was very educational to do and I highly recommended it :) The bootloader successfully gets through to the final call of the hal_system_start() function, which tries to jump to the image, unfortunately the memory map isn't correct so the application never starts.
>
> I'm hoping this problem sounds familiar to someone?
>
> ALan
>
> -----Original Message-----
> From: Alan Graves [mailto:agraves@deltacontrols.com]
> Sent: Wednesday, March 08, 2017 5:23 PM
> To: dev@mynewt.incubator.apache.org
> Subject: RE: New STM32F427xx port
>
> Asserts are better than nothing in the low-level, but not exactly a graceful exit. I definitely have a better idea of what is going on behind the scenes now that I've struggled with this very basic port.
>
> BTW I have an idea of how much work is involved in a project of this magnitude and it's an enormous accomplishment. So nice job everyone on the MyNewt project.
>
> ALan
>
> -----Original Message-----
> From: marko kiiskila [mailto:marko@runtime.io]
> Sent: Wednesday, March 08, 2017 4:14 PM
> To: dev <de...@mynewt.incubator.apache.org>
> Subject: Re: New STM32F427xx port
>
> Cool, nice progress.
>
> I’ll comment more inline.
>
>> On Mar 8, 2017, at 4:00 PM, Alan Graves <ag...@deltacontrols.com> wrote:
>>
>> False alarm! The newt load and debug scripts are working now. I had an error in a .cfg file that was causing an openocd error...
>>
>> ALan
>>
>> -----Original Message-----
>> From: Alan Graves [mailto:agraves@deltacontrols.com]
>> Sent: Wednesday, March 08, 2017 3:12 PM
>> To: dev@mynewt.incubator.apache.org
>> Subject: RE: New STM32F427xx port
>>
>> Wow finally the OS is running, at least under a J-Link debugger, however I'm having issues getting a 'newt load xxx_blinky' to work or even get 'xxx_blinky' operating without using the debugger.
>>
>> Here is what I've had to do to get things kind of going:
>> (1) I discovered that I can muck about with other tools, namely IAR EWARM (under Windows) or JLinkExe (under Linux), to erase the entire MCU Flash memory. This is very important when running 'slinky’!
>
> You can also do this with openocd. ‘mon stm32f2x mass_erase 0’ from gdb would do it.
> Ill-named command, but that should do it.
>
>> (2) I can also run 'openocd' from a terminal to establish a J-Link debugger connection first because the 'newt load xxx_boot' scripts fail to startup the openocd. I can't figure those blasted scripts out!
>> $ openocd -f /usr/share/openocd/scripts/interface/jlink.cfg -f openocd.cfg Open On-Chip Debugger 0.10.0+dev-00092-g77189db (2017-03-01-15:08) Licensed under GNU GPL v2 For bug reports, read
>> http://openocd.org/doc/doxygen/bugs.html
>> Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
>> adapter speed: 2000 kHz
>> adapter_nsrst_delay: 100
>> jtag_ntrst_delay: 100
>> none separate
>> cortex_m reset_config sysresetreq
>> Info : No device selected, using first device.
>> Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46 Info : Hardware version: 8.00 Info : VTarget = 3.319 V Info : clock speed 2000 kHz Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4) Info : JTAG tap: stm32f4x.bs tap/device found: 0x06419041 (mfg: 0x020 (STMicroelectronics), part: 0x6419, ver: 0x0) Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints <snip> File jlink.cfg:
>> interface jlink
>> <eof>
>> File openocd.cfg:
>> set WORKAREASIZE 0x40000
>> source [find target/stm32f4x.cfg]
>> <eof>
>> (3) Then using 'newt debug xxx_boot' in another terminal type 'load' to program the Flash and begin debugging or just exit.
>> (4) Then repeat using 'newt debug xxx_blinky' or 'newt debug xxx_slinky', etc.
>> Needless to say this is an inconvenient process!
>>
>> Some observations:
>> (1) I noticed that I get an assert() message coming from the function log_reboot_pkg_init() which was traced to the fcb_init() function returning rc = -7 (to do with bad MAGIC). I figured out this is because the circular Flash boot log can't be initialized if there is anything other than FF's at Flash location 0x8004000 - hence the need to erase the entire chip.
>
> Yup. I’m thinking we should erase that area if it has unexpected data in it.
> At the moment if fcb_init() backs out due to seeing unexpected magic in it, and log_reboot_pkg_init() asserts.
>
>> (2) Note by overriding slinky's default configuration to log reboots to flash shown below, I was able to get the console up and running ok:
>> File syscfg.yml:
>> # Package: apps/slinky
>> syscfg.vals:
>> # Log reboot messages to a flash circular buffer.
>> REBOOT_LOG_FCB: 0
>> LOG_FCB: 0
>> <eof>
>> (3) I'm assuming that the Flash memory mapping is probably correct. Actually this mapping originated from the existing STM32F407xx, which has up to 1M of on chip Flash so I believe the same memory map should work for 1M version of the STM32F427IG chip that I'm using.
>
> I suspect that’s correct. I’m assuming here that the flash sector boundaries are the same on this model are the same as they are on 407.
>
>> File bsp.yml file:
>> bsp.flash_map:
>> areas:
>> # System areas.
>> FLASH_AREA_BOOTLOADER:
>> device: 0
>> offset: 0x08000000
>> size: 16kB
>> FLASH_AREA_IMAGE_0:
>> device: 0
>> offset: 0x08020000
>> size: 384kB
>> FLASH_AREA_IMAGE_1:
>> device: 0
>> offset: 0x08080000
>> size: 384kB
>> FLASH_AREA_IMAGE_SCRATCH:
>> device: 0
>> offset: 0x080e0000
>> size: 128kB
>>
>> # User areas.
>> FLASH_AREA_REBOOT_LOG:
>> user_id: 0
>> device: 0
>> offset: 0x08004000
>> size: 16kB
>> FLASH_AREA_NFFS:
>> user_id: 1
>> device: 0
>> offset: 0x08008000
>> size: 32kB
>> <eof>
>> BTW Does anyone know why there is a 64K hole above the NFFS Flash area (ie. 0x80010000-0x8001FFFF) that isn't accounted for?
>
> That is just unused by default. You can use it to stash logs, more config etc.
>
>> (4) The SRAM size is a bit bigger so I adjusted the SRAM_SIZE from 128K to 192K in the bsp.h file.
>>
>> Am I missing something else? Any suggestions are welcome.
>
> Linker scripts are the key for RAM size. I assume you meant define RAM_SIZE, not SRAM_SIZE?
> This is used in hal_bsp to figure out the default memory areas to include in coredump, if ppl end up using those.
>
>>
>> ALan
>>
>> -----Original Message-----
>> From: Alan Graves [mailto:agraves@deltacontrols.com]
>> Sent: Monday, March 06, 2017 5:29 PM
>> To: dev@mynewt.incubator.apache.org
>> Subject: RE: New STM32F427xx port
>>
>> Thx Fabio for those tips. I'll keep plugging away at it.
>> ALan
>>
>> -----Original Message-----
>> From: Fabio Utzig [mailto:utzig@utzig.org]
>> Sent: Monday, March 06, 2017 4:42 PM
>> To: dev@mynewt.incubator.apache.org
>> Subject: Re: New STM32F427xx port
>>
>> Hi Alan,
>>
>> I recently created a port for the STM32F7xx, which is not complete due to some missing hal_ drivers, but I upgraded CMSIS to 4.3.0. PR is waiting to be merged:
>>
>> https://github.com/apache/incubator-mynewt-core/pull/179/
>>
>> And I used as base for the startup/etc files STM32Cube V1.6.0. My idea would be to upgrade all STM32Fx ports to that version, to at least have some tracking of what versions are being used, etc, otherwise everything is getting to be messy with lots of different ext files around.
>>
>> Anyway, at least two changes I remember having to do to the startup_*.s:
>>
>> 1) It jumps to "main" at the end of the Reset_Handler. You need to change it to jump to "_start".
>> 2) There is already zeroing of the "bss" section, but you also need to add zeroing of "corebss".
>>
>> Of course the linker script also has to be updated accordingly (sections/labels that match).
>>
>> Cheers,
>> Fabio Utzig
>>
>> On Mon, Mar 6, 2017, at 08:16 PM, Alan Graves wrote:
>>> I've been working on what I thought was a simple port to this
>>> architecture and have a problem with versions for the startup files.
>>> If I understand the STM architecture directories correctly I was
>>> expecting to simply swap out files used by the 'stm32f4discovery'
>>> package (ie. V1.4, dated 09-Jul-2012):
>>> hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
>>> with this one needed by my port:
>>> startup_stm32f427xx.s
>>>
>>> Unfortunately I found that the external CMSIS files located in this
>>> directory are dated much newer (ie. V2.5.1, 28-June-2016):
>>>
>>> hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Sourc
>>> e
>>> /
>>> Templates/gcc/startup_stm32f407xx.s
>>>
>>> Naturally I assumed that this would be a straight forward port since
>>> the microprocessor are very similar. Does anyone have the right
>>> version of the startup file that I can use?
>>>
>>> Note that from what I can tell the include files being used by
>>> 'stm32f4discovery' port are being mixed with an older startup file
>>> version. Even though this appears to be working, I would suggest
>>> that the current STM bsp be brought up to date to use the newest
>>> CMSIS support as the global variables are quite a bit different.
>>> This would save others from running into similar confusion and porting problems.
>>>
>>> ALan
>
Re: New STM32F427xx port
Posted by marko kiiskila <ma...@runtime.io>.
Hi Alan,
it is hard to maintain the right caffeine balance.
I was just starting to scratch my head thinking about what could be going on
when you sent this message.
Keep console open when bringing things up. asserts show up there,
and if the system gets past os_init(), and you have console uart enabled, you’ll
see output if (when) things do not go the right way (aka hard faults and unhandled
interrupts).
> On Mar 9, 2017, at 5:25 PM, Alan Graves <ag...@deltacontrols.com> wrote:
>
> Ignore that last message - I'm gonna choc it up to either too much or too little coffee.
>
> Reprogramming everything and starting fresh showed no weirdness...
>
> ALan
>
> -----Original Message-----
> From: Alan Graves [mailto:agraves@deltacontrols.com]
> Sent: Thursday, March 09, 2017 4:45 PM
> To: dev@mynewt.incubator.apache.org
> Subject: RE: New STM32F427xx port
>
> I have some odd behavior, but I'm sure someone will have an idea of what is happening. I've been debugging this port and things seemed to be running smoothly, so I detached the debugger and power cycled the board. Obviously I was expecting to see the board come up and start blinking a LED, which it does nicely when loaded under the debugger. Unfortunately, without the debugger the bootloader does not vector off to the 'blinky' application as I was expecting. I therefore reconnected the debugger and proceeded to debug the application. After doing a ^C I notice that the debugger shows that the mcu's PC is sitting at the default memory map which has a HardFault_Handler in place of the Reset_Handler. I'm not sure how things got there, so I actually trace through the entire boot up sequence by forcing a jump to the Reset_Handler of the bootloader. BTW this was very educational to do and I highly recommended it :) The bootloader successfully gets through to the final call of the hal_system_start() function, which tries to jump to the image, unfortunately the memory map isn't correct so the application never starts.
>
> I'm hoping this problem sounds familiar to someone?
>
> ALan
>
> -----Original Message-----
> From: Alan Graves [mailto:agraves@deltacontrols.com]
> Sent: Wednesday, March 08, 2017 5:23 PM
> To: dev@mynewt.incubator.apache.org
> Subject: RE: New STM32F427xx port
>
> Asserts are better than nothing in the low-level, but not exactly a graceful exit. I definitely have a better idea of what is going on behind the scenes now that I've struggled with this very basic port.
>
> BTW I have an idea of how much work is involved in a project of this magnitude and it's an enormous accomplishment. So nice job everyone on the MyNewt project.
>
> ALan
>
> -----Original Message-----
> From: marko kiiskila [mailto:marko@runtime.io]
> Sent: Wednesday, March 08, 2017 4:14 PM
> To: dev <de...@mynewt.incubator.apache.org>
> Subject: Re: New STM32F427xx port
>
> Cool, nice progress.
>
> I’ll comment more inline.
>
>> On Mar 8, 2017, at 4:00 PM, Alan Graves <ag...@deltacontrols.com> wrote:
>>
>> False alarm! The newt load and debug scripts are working now. I had an error in a .cfg file that was causing an openocd error...
>>
>> ALan
>>
>> -----Original Message-----
>> From: Alan Graves [mailto:agraves@deltacontrols.com]
>> Sent: Wednesday, March 08, 2017 3:12 PM
>> To: dev@mynewt.incubator.apache.org
>> Subject: RE: New STM32F427xx port
>>
>> Wow finally the OS is running, at least under a J-Link debugger, however I'm having issues getting a 'newt load xxx_blinky' to work or even get 'xxx_blinky' operating without using the debugger.
>>
>> Here is what I've had to do to get things kind of going:
>> (1) I discovered that I can muck about with other tools, namely IAR EWARM (under Windows) or JLinkExe (under Linux), to erase the entire MCU Flash memory. This is very important when running 'slinky’!
>
> You can also do this with openocd. ‘mon stm32f2x mass_erase 0’ from gdb would do it.
> Ill-named command, but that should do it.
>
>> (2) I can also run 'openocd' from a terminal to establish a J-Link debugger connection first because the 'newt load xxx_boot' scripts fail to startup the openocd. I can't figure those blasted scripts out!
>> $ openocd -f /usr/share/openocd/scripts/interface/jlink.cfg -f openocd.cfg Open On-Chip Debugger 0.10.0+dev-00092-g77189db (2017-03-01-15:08) Licensed under GNU GPL v2 For bug reports, read
>> http://openocd.org/doc/doxygen/bugs.html
>> Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
>> adapter speed: 2000 kHz
>> adapter_nsrst_delay: 100
>> jtag_ntrst_delay: 100
>> none separate
>> cortex_m reset_config sysresetreq
>> Info : No device selected, using first device.
>> Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46 Info : Hardware version: 8.00 Info : VTarget = 3.319 V Info : clock speed 2000 kHz Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4) Info : JTAG tap: stm32f4x.bs tap/device found: 0x06419041 (mfg: 0x020 (STMicroelectronics), part: 0x6419, ver: 0x0) Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints <snip> File jlink.cfg:
>> interface jlink
>> <eof>
>> File openocd.cfg:
>> set WORKAREASIZE 0x40000
>> source [find target/stm32f4x.cfg]
>> <eof>
>> (3) Then using 'newt debug xxx_boot' in another terminal type 'load' to program the Flash and begin debugging or just exit.
>> (4) Then repeat using 'newt debug xxx_blinky' or 'newt debug xxx_slinky', etc.
>> Needless to say this is an inconvenient process!
>>
>> Some observations:
>> (1) I noticed that I get an assert() message coming from the function log_reboot_pkg_init() which was traced to the fcb_init() function returning rc = -7 (to do with bad MAGIC). I figured out this is because the circular Flash boot log can't be initialized if there is anything other than FF's at Flash location 0x8004000 - hence the need to erase the entire chip.
>
> Yup. I’m thinking we should erase that area if it has unexpected data in it.
> At the moment if fcb_init() backs out due to seeing unexpected magic in it, and log_reboot_pkg_init() asserts.
>
>> (2) Note by overriding slinky's default configuration to log reboots to flash shown below, I was able to get the console up and running ok:
>> File syscfg.yml:
>> # Package: apps/slinky
>> syscfg.vals:
>> # Log reboot messages to a flash circular buffer.
>> REBOOT_LOG_FCB: 0
>> LOG_FCB: 0
>> <eof>
>> (3) I'm assuming that the Flash memory mapping is probably correct. Actually this mapping originated from the existing STM32F407xx, which has up to 1M of on chip Flash so I believe the same memory map should work for 1M version of the STM32F427IG chip that I'm using.
>
> I suspect that’s correct. I’m assuming here that the flash sector boundaries are the same on this model are the same as they are on 407.
>
>> File bsp.yml file:
>> bsp.flash_map:
>> areas:
>> # System areas.
>> FLASH_AREA_BOOTLOADER:
>> device: 0
>> offset: 0x08000000
>> size: 16kB
>> FLASH_AREA_IMAGE_0:
>> device: 0
>> offset: 0x08020000
>> size: 384kB
>> FLASH_AREA_IMAGE_1:
>> device: 0
>> offset: 0x08080000
>> size: 384kB
>> FLASH_AREA_IMAGE_SCRATCH:
>> device: 0
>> offset: 0x080e0000
>> size: 128kB
>>
>> # User areas.
>> FLASH_AREA_REBOOT_LOG:
>> user_id: 0
>> device: 0
>> offset: 0x08004000
>> size: 16kB
>> FLASH_AREA_NFFS:
>> user_id: 1
>> device: 0
>> offset: 0x08008000
>> size: 32kB
>> <eof>
>> BTW Does anyone know why there is a 64K hole above the NFFS Flash area (ie. 0x80010000-0x8001FFFF) that isn't accounted for?
>
> That is just unused by default. You can use it to stash logs, more config etc.
>
>> (4) The SRAM size is a bit bigger so I adjusted the SRAM_SIZE from 128K to 192K in the bsp.h file.
>>
>> Am I missing something else? Any suggestions are welcome.
>
> Linker scripts are the key for RAM size. I assume you meant define RAM_SIZE, not SRAM_SIZE?
> This is used in hal_bsp to figure out the default memory areas to include in coredump, if ppl end up using those.
>
>>
>> ALan
>>
>> -----Original Message-----
>> From: Alan Graves [mailto:agraves@deltacontrols.com]
>> Sent: Monday, March 06, 2017 5:29 PM
>> To: dev@mynewt.incubator.apache.org
>> Subject: RE: New STM32F427xx port
>>
>> Thx Fabio for those tips. I'll keep plugging away at it.
>> ALan
>>
>> -----Original Message-----
>> From: Fabio Utzig [mailto:utzig@utzig.org]
>> Sent: Monday, March 06, 2017 4:42 PM
>> To: dev@mynewt.incubator.apache.org
>> Subject: Re: New STM32F427xx port
>>
>> Hi Alan,
>>
>> I recently created a port for the STM32F7xx, which is not complete due to some missing hal_ drivers, but I upgraded CMSIS to 4.3.0. PR is waiting to be merged:
>>
>> https://github.com/apache/incubator-mynewt-core/pull/179/
>>
>> And I used as base for the startup/etc files STM32Cube V1.6.0. My idea would be to upgrade all STM32Fx ports to that version, to at least have some tracking of what versions are being used, etc, otherwise everything is getting to be messy with lots of different ext files around.
>>
>> Anyway, at least two changes I remember having to do to the startup_*.s:
>>
>> 1) It jumps to "main" at the end of the Reset_Handler. You need to change it to jump to "_start".
>> 2) There is already zeroing of the "bss" section, but you also need to add zeroing of "corebss".
>>
>> Of course the linker script also has to be updated accordingly (sections/labels that match).
>>
>> Cheers,
>> Fabio Utzig
>>
>> On Mon, Mar 6, 2017, at 08:16 PM, Alan Graves wrote:
>>> I've been working on what I thought was a simple port to this
>>> architecture and have a problem with versions for the startup files.
>>> If I understand the STM architecture directories correctly I was
>>> expecting to simply swap out files used by the 'stm32f4discovery'
>>> package (ie. V1.4, dated 09-Jul-2012):
>>> hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
>>> with this one needed by my port:
>>> startup_stm32f427xx.s
>>>
>>> Unfortunately I found that the external CMSIS files located in this
>>> directory are dated much newer (ie. V2.5.1, 28-June-2016):
>>>
>>> hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Source
>>> /
>>> Templates/gcc/startup_stm32f407xx.s
>>>
>>> Naturally I assumed that this would be a straight forward port since
>>> the microprocessor are very similar. Does anyone have the right
>>> version of the startup file that I can use?
>>>
>>> Note that from what I can tell the include files being used by
>>> 'stm32f4discovery' port are being mixed with an older startup file
>>> version. Even though this appears to be working, I would suggest that
>>> the current STM bsp be brought up to date to use the newest CMSIS
>>> support as the global variables are quite a bit different. This would
>>> save others from running into similar confusion and porting problems.
>>>
>>> ALan
>
RE: New STM32F427xx port
Posted by Alan Graves <ag...@deltacontrols.com>.
Ignore that last message - I'm gonna choc it up to either too much or too little coffee.
Reprogramming everything and starting fresh showed no weirdness...
ALan
-----Original Message-----
From: Alan Graves [mailto:agraves@deltacontrols.com]
Sent: Thursday, March 09, 2017 4:45 PM
To: dev@mynewt.incubator.apache.org
Subject: RE: New STM32F427xx port
I have some odd behavior, but I'm sure someone will have an idea of what is happening. I've been debugging this port and things seemed to be running smoothly, so I detached the debugger and power cycled the board. Obviously I was expecting to see the board come up and start blinking a LED, which it does nicely when loaded under the debugger. Unfortunately, without the debugger the bootloader does not vector off to the 'blinky' application as I was expecting. I therefore reconnected the debugger and proceeded to debug the application. After doing a ^C I notice that the debugger shows that the mcu's PC is sitting at the default memory map which has a HardFault_Handler in place of the Reset_Handler. I'm not sure how things got there, so I actually trace through the entire boot up sequence by forcing a jump to the Reset_Handler of the bootloader. BTW this was very educational to do and I highly recommended it :) The bootloader successfully gets through to the final call of the hal_system_start() function, which tries to jump to the image, unfortunately the memory map isn't correct so the application never starts.
I'm hoping this problem sounds familiar to someone?
ALan
-----Original Message-----
From: Alan Graves [mailto:agraves@deltacontrols.com]
Sent: Wednesday, March 08, 2017 5:23 PM
To: dev@mynewt.incubator.apache.org
Subject: RE: New STM32F427xx port
Asserts are better than nothing in the low-level, but not exactly a graceful exit. I definitely have a better idea of what is going on behind the scenes now that I've struggled with this very basic port.
BTW I have an idea of how much work is involved in a project of this magnitude and it's an enormous accomplishment. So nice job everyone on the MyNewt project.
ALan
-----Original Message-----
From: marko kiiskila [mailto:marko@runtime.io]
Sent: Wednesday, March 08, 2017 4:14 PM
To: dev <de...@mynewt.incubator.apache.org>
Subject: Re: New STM32F427xx port
Cool, nice progress.
I’ll comment more inline.
> On Mar 8, 2017, at 4:00 PM, Alan Graves <ag...@deltacontrols.com> wrote:
>
> False alarm! The newt load and debug scripts are working now. I had an error in a .cfg file that was causing an openocd error...
>
> ALan
>
> -----Original Message-----
> From: Alan Graves [mailto:agraves@deltacontrols.com]
> Sent: Wednesday, March 08, 2017 3:12 PM
> To: dev@mynewt.incubator.apache.org
> Subject: RE: New STM32F427xx port
>
> Wow finally the OS is running, at least under a J-Link debugger, however I'm having issues getting a 'newt load xxx_blinky' to work or even get 'xxx_blinky' operating without using the debugger.
>
> Here is what I've had to do to get things kind of going:
> (1) I discovered that I can muck about with other tools, namely IAR EWARM (under Windows) or JLinkExe (under Linux), to erase the entire MCU Flash memory. This is very important when running 'slinky’!
You can also do this with openocd. ‘mon stm32f2x mass_erase 0’ from gdb would do it.
Ill-named command, but that should do it.
> (2) I can also run 'openocd' from a terminal to establish a J-Link debugger connection first because the 'newt load xxx_boot' scripts fail to startup the openocd. I can't figure those blasted scripts out!
> $ openocd -f /usr/share/openocd/scripts/interface/jlink.cfg -f openocd.cfg Open On-Chip Debugger 0.10.0+dev-00092-g77189db (2017-03-01-15:08) Licensed under GNU GPL v2 For bug reports, read
> http://openocd.org/doc/doxygen/bugs.html
> Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
> adapter speed: 2000 kHz
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> none separate
> cortex_m reset_config sysresetreq
> Info : No device selected, using first device.
> Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46 Info : Hardware version: 8.00 Info : VTarget = 3.319 V Info : clock speed 2000 kHz Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4) Info : JTAG tap: stm32f4x.bs tap/device found: 0x06419041 (mfg: 0x020 (STMicroelectronics), part: 0x6419, ver: 0x0) Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints <snip> File jlink.cfg:
> interface jlink
> <eof>
> File openocd.cfg:
> set WORKAREASIZE 0x40000
> source [find target/stm32f4x.cfg]
> <eof>
> (3) Then using 'newt debug xxx_boot' in another terminal type 'load' to program the Flash and begin debugging or just exit.
> (4) Then repeat using 'newt debug xxx_blinky' or 'newt debug xxx_slinky', etc.
> Needless to say this is an inconvenient process!
>
> Some observations:
> (1) I noticed that I get an assert() message coming from the function log_reboot_pkg_init() which was traced to the fcb_init() function returning rc = -7 (to do with bad MAGIC). I figured out this is because the circular Flash boot log can't be initialized if there is anything other than FF's at Flash location 0x8004000 - hence the need to erase the entire chip.
Yup. I’m thinking we should erase that area if it has unexpected data in it.
At the moment if fcb_init() backs out due to seeing unexpected magic in it, and log_reboot_pkg_init() asserts.
> (2) Note by overriding slinky's default configuration to log reboots to flash shown below, I was able to get the console up and running ok:
> File syscfg.yml:
> # Package: apps/slinky
> syscfg.vals:
> # Log reboot messages to a flash circular buffer.
> REBOOT_LOG_FCB: 0
> LOG_FCB: 0
> <eof>
> (3) I'm assuming that the Flash memory mapping is probably correct. Actually this mapping originated from the existing STM32F407xx, which has up to 1M of on chip Flash so I believe the same memory map should work for 1M version of the STM32F427IG chip that I'm using.
I suspect that’s correct. I’m assuming here that the flash sector boundaries are the same on this model are the same as they are on 407.
> File bsp.yml file:
> bsp.flash_map:
> areas:
> # System areas.
> FLASH_AREA_BOOTLOADER:
> device: 0
> offset: 0x08000000
> size: 16kB
> FLASH_AREA_IMAGE_0:
> device: 0
> offset: 0x08020000
> size: 384kB
> FLASH_AREA_IMAGE_1:
> device: 0
> offset: 0x08080000
> size: 384kB
> FLASH_AREA_IMAGE_SCRATCH:
> device: 0
> offset: 0x080e0000
> size: 128kB
>
> # User areas.
> FLASH_AREA_REBOOT_LOG:
> user_id: 0
> device: 0
> offset: 0x08004000
> size: 16kB
> FLASH_AREA_NFFS:
> user_id: 1
> device: 0
> offset: 0x08008000
> size: 32kB
> <eof>
> BTW Does anyone know why there is a 64K hole above the NFFS Flash area (ie. 0x80010000-0x8001FFFF) that isn't accounted for?
That is just unused by default. You can use it to stash logs, more config etc.
> (4) The SRAM size is a bit bigger so I adjusted the SRAM_SIZE from 128K to 192K in the bsp.h file.
>
> Am I missing something else? Any suggestions are welcome.
Linker scripts are the key for RAM size. I assume you meant define RAM_SIZE, not SRAM_SIZE?
This is used in hal_bsp to figure out the default memory areas to include in coredump, if ppl end up using those.
>
> ALan
>
> -----Original Message-----
> From: Alan Graves [mailto:agraves@deltacontrols.com]
> Sent: Monday, March 06, 2017 5:29 PM
> To: dev@mynewt.incubator.apache.org
> Subject: RE: New STM32F427xx port
>
> Thx Fabio for those tips. I'll keep plugging away at it.
> ALan
>
> -----Original Message-----
> From: Fabio Utzig [mailto:utzig@utzig.org]
> Sent: Monday, March 06, 2017 4:42 PM
> To: dev@mynewt.incubator.apache.org
> Subject: Re: New STM32F427xx port
>
> Hi Alan,
>
> I recently created a port for the STM32F7xx, which is not complete due to some missing hal_ drivers, but I upgraded CMSIS to 4.3.0. PR is waiting to be merged:
>
> https://github.com/apache/incubator-mynewt-core/pull/179/
>
> And I used as base for the startup/etc files STM32Cube V1.6.0. My idea would be to upgrade all STM32Fx ports to that version, to at least have some tracking of what versions are being used, etc, otherwise everything is getting to be messy with lots of different ext files around.
>
> Anyway, at least two changes I remember having to do to the startup_*.s:
>
> 1) It jumps to "main" at the end of the Reset_Handler. You need to change it to jump to "_start".
> 2) There is already zeroing of the "bss" section, but you also need to add zeroing of "corebss".
>
> Of course the linker script also has to be updated accordingly (sections/labels that match).
>
> Cheers,
> Fabio Utzig
>
> On Mon, Mar 6, 2017, at 08:16 PM, Alan Graves wrote:
>> I've been working on what I thought was a simple port to this
>> architecture and have a problem with versions for the startup files.
>> If I understand the STM architecture directories correctly I was
>> expecting to simply swap out files used by the 'stm32f4discovery'
>> package (ie. V1.4, dated 09-Jul-2012):
>> hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
>> with this one needed by my port:
>> startup_stm32f427xx.s
>>
>> Unfortunately I found that the external CMSIS files located in this
>> directory are dated much newer (ie. V2.5.1, 28-June-2016):
>>
>> hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Source
>> /
>> Templates/gcc/startup_stm32f407xx.s
>>
>> Naturally I assumed that this would be a straight forward port since
>> the microprocessor are very similar. Does anyone have the right
>> version of the startup file that I can use?
>>
>> Note that from what I can tell the include files being used by
>> 'stm32f4discovery' port are being mixed with an older startup file
>> version. Even though this appears to be working, I would suggest that
>> the current STM bsp be brought up to date to use the newest CMSIS
>> support as the global variables are quite a bit different. This would
>> save others from running into similar confusion and porting problems.
>>
>> ALan
RE: New STM32F427xx port
Posted by Alan Graves <ag...@deltacontrols.com>.
I have some odd behavior, but I'm sure someone will have an idea of what is happening. I've been debugging this port and things seemed to be running smoothly, so I detached the debugger and power cycled the board. Obviously I was expecting to see the board come up and start blinking a LED, which it does nicely when loaded under the debugger. Unfortunately, without the debugger the bootloader does not vector off to the 'blinky' application as I was expecting. I therefore reconnected the debugger and proceeded to debug the application. After doing a ^C I notice that the debugger shows that the mcu's PC is sitting at the default memory map which has a HardFault_Handler in place of the Reset_Handler. I'm not sure how things got there, so I actually trace through the entire boot up sequence by forcing a jump to the Reset_Handler of the bootloader. BTW this was very educational to do and I highly recommended it :) The bootloader successfully gets through to the final call of the hal_system_start() function, which tries to jump to the image, unfortunately the memory map isn't correct so the application never starts.
I'm hoping this problem sounds familiar to someone?
ALan
-----Original Message-----
From: Alan Graves [mailto:agraves@deltacontrols.com]
Sent: Wednesday, March 08, 2017 5:23 PM
To: dev@mynewt.incubator.apache.org
Subject: RE: New STM32F427xx port
Asserts are better than nothing in the low-level, but not exactly a graceful exit. I definitely have a better idea of what is going on behind the scenes now that I've struggled with this very basic port.
BTW I have an idea of how much work is involved in a project of this magnitude and it's an enormous accomplishment. So nice job everyone on the MyNewt project.
ALan
-----Original Message-----
From: marko kiiskila [mailto:marko@runtime.io]
Sent: Wednesday, March 08, 2017 4:14 PM
To: dev <de...@mynewt.incubator.apache.org>
Subject: Re: New STM32F427xx port
Cool, nice progress.
I’ll comment more inline.
> On Mar 8, 2017, at 4:00 PM, Alan Graves <ag...@deltacontrols.com> wrote:
>
> False alarm! The newt load and debug scripts are working now. I had an error in a .cfg file that was causing an openocd error...
>
> ALan
>
> -----Original Message-----
> From: Alan Graves [mailto:agraves@deltacontrols.com]
> Sent: Wednesday, March 08, 2017 3:12 PM
> To: dev@mynewt.incubator.apache.org
> Subject: RE: New STM32F427xx port
>
> Wow finally the OS is running, at least under a J-Link debugger, however I'm having issues getting a 'newt load xxx_blinky' to work or even get 'xxx_blinky' operating without using the debugger.
>
> Here is what I've had to do to get things kind of going:
> (1) I discovered that I can muck about with other tools, namely IAR EWARM (under Windows) or JLinkExe (under Linux), to erase the entire MCU Flash memory. This is very important when running 'slinky’!
You can also do this with openocd. ‘mon stm32f2x mass_erase 0’ from gdb would do it.
Ill-named command, but that should do it.
> (2) I can also run 'openocd' from a terminal to establish a J-Link debugger connection first because the 'newt load xxx_boot' scripts fail to startup the openocd. I can't figure those blasted scripts out!
> $ openocd -f /usr/share/openocd/scripts/interface/jlink.cfg -f openocd.cfg Open On-Chip Debugger 0.10.0+dev-00092-g77189db (2017-03-01-15:08) Licensed under GNU GPL v2 For bug reports, read
> http://openocd.org/doc/doxygen/bugs.html
> Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
> adapter speed: 2000 kHz
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> none separate
> cortex_m reset_config sysresetreq
> Info : No device selected, using first device.
> Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46 Info : Hardware version: 8.00 Info : VTarget = 3.319 V Info : clock speed 2000 kHz Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4) Info : JTAG tap: stm32f4x.bs tap/device found: 0x06419041 (mfg: 0x020 (STMicroelectronics), part: 0x6419, ver: 0x0) Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints <snip> File jlink.cfg:
> interface jlink
> <eof>
> File openocd.cfg:
> set WORKAREASIZE 0x40000
> source [find target/stm32f4x.cfg]
> <eof>
> (3) Then using 'newt debug xxx_boot' in another terminal type 'load' to program the Flash and begin debugging or just exit.
> (4) Then repeat using 'newt debug xxx_blinky' or 'newt debug xxx_slinky', etc.
> Needless to say this is an inconvenient process!
>
> Some observations:
> (1) I noticed that I get an assert() message coming from the function log_reboot_pkg_init() which was traced to the fcb_init() function returning rc = -7 (to do with bad MAGIC). I figured out this is because the circular Flash boot log can't be initialized if there is anything other than FF's at Flash location 0x8004000 - hence the need to erase the entire chip.
Yup. I’m thinking we should erase that area if it has unexpected data in it.
At the moment if fcb_init() backs out due to seeing unexpected magic in it, and log_reboot_pkg_init() asserts.
> (2) Note by overriding slinky's default configuration to log reboots to flash shown below, I was able to get the console up and running ok:
> File syscfg.yml:
> # Package: apps/slinky
> syscfg.vals:
> # Log reboot messages to a flash circular buffer.
> REBOOT_LOG_FCB: 0
> LOG_FCB: 0
> <eof>
> (3) I'm assuming that the Flash memory mapping is probably correct. Actually this mapping originated from the existing STM32F407xx, which has up to 1M of on chip Flash so I believe the same memory map should work for 1M version of the STM32F427IG chip that I'm using.
I suspect that’s correct. I’m assuming here that the flash sector boundaries are the same on this model are the same as they are on 407.
> File bsp.yml file:
> bsp.flash_map:
> areas:
> # System areas.
> FLASH_AREA_BOOTLOADER:
> device: 0
> offset: 0x08000000
> size: 16kB
> FLASH_AREA_IMAGE_0:
> device: 0
> offset: 0x08020000
> size: 384kB
> FLASH_AREA_IMAGE_1:
> device: 0
> offset: 0x08080000
> size: 384kB
> FLASH_AREA_IMAGE_SCRATCH:
> device: 0
> offset: 0x080e0000
> size: 128kB
>
> # User areas.
> FLASH_AREA_REBOOT_LOG:
> user_id: 0
> device: 0
> offset: 0x08004000
> size: 16kB
> FLASH_AREA_NFFS:
> user_id: 1
> device: 0
> offset: 0x08008000
> size: 32kB
> <eof>
> BTW Does anyone know why there is a 64K hole above the NFFS Flash area (ie. 0x80010000-0x8001FFFF) that isn't accounted for?
That is just unused by default. You can use it to stash logs, more config etc.
> (4) The SRAM size is a bit bigger so I adjusted the SRAM_SIZE from 128K to 192K in the bsp.h file.
>
> Am I missing something else? Any suggestions are welcome.
Linker scripts are the key for RAM size. I assume you meant define RAM_SIZE, not SRAM_SIZE?
This is used in hal_bsp to figure out the default memory areas to include in coredump, if ppl end up using those.
>
> ALan
>
> -----Original Message-----
> From: Alan Graves [mailto:agraves@deltacontrols.com]
> Sent: Monday, March 06, 2017 5:29 PM
> To: dev@mynewt.incubator.apache.org
> Subject: RE: New STM32F427xx port
>
> Thx Fabio for those tips. I'll keep plugging away at it.
> ALan
>
> -----Original Message-----
> From: Fabio Utzig [mailto:utzig@utzig.org]
> Sent: Monday, March 06, 2017 4:42 PM
> To: dev@mynewt.incubator.apache.org
> Subject: Re: New STM32F427xx port
>
> Hi Alan,
>
> I recently created a port for the STM32F7xx, which is not complete due to some missing hal_ drivers, but I upgraded CMSIS to 4.3.0. PR is waiting to be merged:
>
> https://github.com/apache/incubator-mynewt-core/pull/179/
>
> And I used as base for the startup/etc files STM32Cube V1.6.0. My idea would be to upgrade all STM32Fx ports to that version, to at least have some tracking of what versions are being used, etc, otherwise everything is getting to be messy with lots of different ext files around.
>
> Anyway, at least two changes I remember having to do to the startup_*.s:
>
> 1) It jumps to "main" at the end of the Reset_Handler. You need to change it to jump to "_start".
> 2) There is already zeroing of the "bss" section, but you also need to add zeroing of "corebss".
>
> Of course the linker script also has to be updated accordingly (sections/labels that match).
>
> Cheers,
> Fabio Utzig
>
> On Mon, Mar 6, 2017, at 08:16 PM, Alan Graves wrote:
>> I've been working on what I thought was a simple port to this
>> architecture and have a problem with versions for the startup files.
>> If I understand the STM architecture directories correctly I was
>> expecting to simply swap out files used by the 'stm32f4discovery'
>> package (ie. V1.4, dated 09-Jul-2012):
>> hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
>> with this one needed by my port:
>> startup_stm32f427xx.s
>>
>> Unfortunately I found that the external CMSIS files located in this
>> directory are dated much newer (ie. V2.5.1, 28-June-2016):
>>
>> hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Source
>> /
>> Templates/gcc/startup_stm32f407xx.s
>>
>> Naturally I assumed that this would be a straight forward port since
>> the microprocessor are very similar. Does anyone have the right
>> version of the startup file that I can use?
>>
>> Note that from what I can tell the include files being used by
>> 'stm32f4discovery' port are being mixed with an older startup file
>> version. Even though this appears to be working, I would suggest that
>> the current STM bsp be brought up to date to use the newest CMSIS
>> support as the global variables are quite a bit different. This would
>> save others from running into similar confusion and porting problems.
>>
>> ALan
RE: New STM32F427xx port
Posted by Alan Graves <ag...@deltacontrols.com>.
Asserts are better than nothing in the low-level, but not exactly a graceful exit. I definitely have a better idea of what is going on behind the scenes now that I've struggled with this very basic port.
BTW I have an idea of how much work is involved in a project of this magnitude and it's an enormous accomplishment. So nice job everyone on the MyNewt project.
ALan
-----Original Message-----
From: marko kiiskila [mailto:marko@runtime.io]
Sent: Wednesday, March 08, 2017 4:14 PM
To: dev <de...@mynewt.incubator.apache.org>
Subject: Re: New STM32F427xx port
Cool, nice progress.
I’ll comment more inline.
> On Mar 8, 2017, at 4:00 PM, Alan Graves <ag...@deltacontrols.com> wrote:
>
> False alarm! The newt load and debug scripts are working now. I had an error in a .cfg file that was causing an openocd error...
>
> ALan
>
> -----Original Message-----
> From: Alan Graves [mailto:agraves@deltacontrols.com]
> Sent: Wednesday, March 08, 2017 3:12 PM
> To: dev@mynewt.incubator.apache.org
> Subject: RE: New STM32F427xx port
>
> Wow finally the OS is running, at least under a J-Link debugger, however I'm having issues getting a 'newt load xxx_blinky' to work or even get 'xxx_blinky' operating without using the debugger.
>
> Here is what I've had to do to get things kind of going:
> (1) I discovered that I can muck about with other tools, namely IAR EWARM (under Windows) or JLinkExe (under Linux), to erase the entire MCU Flash memory. This is very important when running 'slinky’!
You can also do this with openocd. ‘mon stm32f2x mass_erase 0’ from gdb would do it.
Ill-named command, but that should do it.
> (2) I can also run 'openocd' from a terminal to establish a J-Link debugger connection first because the 'newt load xxx_boot' scripts fail to startup the openocd. I can't figure those blasted scripts out!
> $ openocd -f /usr/share/openocd/scripts/interface/jlink.cfg -f openocd.cfg Open On-Chip Debugger 0.10.0+dev-00092-g77189db (2017-03-01-15:08) Licensed under GNU GPL v2 For bug reports, read
> http://openocd.org/doc/doxygen/bugs.html
> Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
> adapter speed: 2000 kHz
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> none separate
> cortex_m reset_config sysresetreq
> Info : No device selected, using first device.
> Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46 Info : Hardware version: 8.00 Info : VTarget = 3.319 V Info : clock speed 2000 kHz Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4) Info : JTAG tap: stm32f4x.bs tap/device found: 0x06419041 (mfg: 0x020 (STMicroelectronics), part: 0x6419, ver: 0x0) Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints <snip> File jlink.cfg:
> interface jlink
> <eof>
> File openocd.cfg:
> set WORKAREASIZE 0x40000
> source [find target/stm32f4x.cfg]
> <eof>
> (3) Then using 'newt debug xxx_boot' in another terminal type 'load' to program the Flash and begin debugging or just exit.
> (4) Then repeat using 'newt debug xxx_blinky' or 'newt debug xxx_slinky', etc.
> Needless to say this is an inconvenient process!
>
> Some observations:
> (1) I noticed that I get an assert() message coming from the function log_reboot_pkg_init() which was traced to the fcb_init() function returning rc = -7 (to do with bad MAGIC). I figured out this is because the circular Flash boot log can't be initialized if there is anything other than FF's at Flash location 0x8004000 - hence the need to erase the entire chip.
Yup. I’m thinking we should erase that area if it has unexpected data in it.
At the moment if fcb_init() backs out due to seeing unexpected magic in it, and log_reboot_pkg_init() asserts.
> (2) Note by overriding slinky's default configuration to log reboots to flash shown below, I was able to get the console up and running ok:
> File syscfg.yml:
> # Package: apps/slinky
> syscfg.vals:
> # Log reboot messages to a flash circular buffer.
> REBOOT_LOG_FCB: 0
> LOG_FCB: 0
> <eof>
> (3) I'm assuming that the Flash memory mapping is probably correct. Actually this mapping originated from the existing STM32F407xx, which has up to 1M of on chip Flash so I believe the same memory map should work for 1M version of the STM32F427IG chip that I'm using.
I suspect that’s correct. I’m assuming here that the flash sector boundaries are the same on this model are the same as they are on 407.
> File bsp.yml file:
> bsp.flash_map:
> areas:
> # System areas.
> FLASH_AREA_BOOTLOADER:
> device: 0
> offset: 0x08000000
> size: 16kB
> FLASH_AREA_IMAGE_0:
> device: 0
> offset: 0x08020000
> size: 384kB
> FLASH_AREA_IMAGE_1:
> device: 0
> offset: 0x08080000
> size: 384kB
> FLASH_AREA_IMAGE_SCRATCH:
> device: 0
> offset: 0x080e0000
> size: 128kB
>
> # User areas.
> FLASH_AREA_REBOOT_LOG:
> user_id: 0
> device: 0
> offset: 0x08004000
> size: 16kB
> FLASH_AREA_NFFS:
> user_id: 1
> device: 0
> offset: 0x08008000
> size: 32kB
> <eof>
> BTW Does anyone know why there is a 64K hole above the NFFS Flash area (ie. 0x80010000-0x8001FFFF) that isn't accounted for?
That is just unused by default. You can use it to stash logs, more config etc.
> (4) The SRAM size is a bit bigger so I adjusted the SRAM_SIZE from 128K to 192K in the bsp.h file.
>
> Am I missing something else? Any suggestions are welcome.
Linker scripts are the key for RAM size. I assume you meant define RAM_SIZE, not SRAM_SIZE?
This is used in hal_bsp to figure out the default memory areas to include in coredump, if ppl end up using those.
>
> ALan
>
> -----Original Message-----
> From: Alan Graves [mailto:agraves@deltacontrols.com]
> Sent: Monday, March 06, 2017 5:29 PM
> To: dev@mynewt.incubator.apache.org
> Subject: RE: New STM32F427xx port
>
> Thx Fabio for those tips. I'll keep plugging away at it.
> ALan
>
> -----Original Message-----
> From: Fabio Utzig [mailto:utzig@utzig.org]
> Sent: Monday, March 06, 2017 4:42 PM
> To: dev@mynewt.incubator.apache.org
> Subject: Re: New STM32F427xx port
>
> Hi Alan,
>
> I recently created a port for the STM32F7xx, which is not complete due to some missing hal_ drivers, but I upgraded CMSIS to 4.3.0. PR is waiting to be merged:
>
> https://github.com/apache/incubator-mynewt-core/pull/179/
>
> And I used as base for the startup/etc files STM32Cube V1.6.0. My idea would be to upgrade all STM32Fx ports to that version, to at least have some tracking of what versions are being used, etc, otherwise everything is getting to be messy with lots of different ext files around.
>
> Anyway, at least two changes I remember having to do to the startup_*.s:
>
> 1) It jumps to "main" at the end of the Reset_Handler. You need to change it to jump to "_start".
> 2) There is already zeroing of the "bss" section, but you also need to add zeroing of "corebss".
>
> Of course the linker script also has to be updated accordingly (sections/labels that match).
>
> Cheers,
> Fabio Utzig
>
> On Mon, Mar 6, 2017, at 08:16 PM, Alan Graves wrote:
>> I've been working on what I thought was a simple port to this
>> architecture and have a problem with versions for the startup files.
>> If I understand the STM architecture directories correctly I was
>> expecting to simply swap out files used by the 'stm32f4discovery'
>> package (ie. V1.4, dated 09-Jul-2012):
>> hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
>> with this one needed by my port:
>> startup_stm32f427xx.s
>>
>> Unfortunately I found that the external CMSIS files located in this
>> directory are dated much newer (ie. V2.5.1, 28-June-2016):
>>
>> hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Source
>> /
>> Templates/gcc/startup_stm32f407xx.s
>>
>> Naturally I assumed that this would be a straight forward port since
>> the microprocessor are very similar. Does anyone have the right
>> version of the startup file that I can use?
>>
>> Note that from what I can tell the include files being used by
>> 'stm32f4discovery' port are being mixed with an older startup file
>> version. Even though this appears to be working, I would suggest that
>> the current STM bsp be brought up to date to use the newest CMSIS
>> support as the global variables are quite a bit different. This would
>> save others from running into similar confusion and porting problems.
>>
>> ALan
Re: New STM32F427xx port
Posted by marko kiiskila <ma...@runtime.io>.
Cool, nice progress.
I’ll comment more inline.
> On Mar 8, 2017, at 4:00 PM, Alan Graves <ag...@deltacontrols.com> wrote:
>
> False alarm! The newt load and debug scripts are working now. I had an error in a .cfg file that was causing an openocd error...
>
> ALan
>
> -----Original Message-----
> From: Alan Graves [mailto:agraves@deltacontrols.com]
> Sent: Wednesday, March 08, 2017 3:12 PM
> To: dev@mynewt.incubator.apache.org
> Subject: RE: New STM32F427xx port
>
> Wow finally the OS is running, at least under a J-Link debugger, however I'm having issues getting a 'newt load xxx_blinky' to work or even get 'xxx_blinky' operating without using the debugger.
>
> Here is what I've had to do to get things kind of going:
> (1) I discovered that I can muck about with other tools, namely IAR EWARM (under Windows) or JLinkExe (under Linux), to erase the entire MCU Flash memory. This is very important when running 'slinky’!
You can also do this with openocd. ‘mon stm32f2x mass_erase 0’ from gdb would do it.
Ill-named command, but that should do it.
> (2) I can also run 'openocd' from a terminal to establish a J-Link debugger connection first because the 'newt load xxx_boot' scripts fail to startup the openocd. I can't figure those blasted scripts out!
> $ openocd -f /usr/share/openocd/scripts/interface/jlink.cfg -f openocd.cfg Open On-Chip Debugger 0.10.0+dev-00092-g77189db (2017-03-01-15:08) Licensed under GNU GPL v2 For bug reports, read
> http://openocd.org/doc/doxygen/bugs.html
> Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
> adapter speed: 2000 kHz
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> none separate
> cortex_m reset_config sysresetreq
> Info : No device selected, using first device.
> Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46 Info : Hardware version: 8.00 Info : VTarget = 3.319 V Info : clock speed 2000 kHz Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4) Info : JTAG tap: stm32f4x.bs tap/device found: 0x06419041 (mfg: 0x020 (STMicroelectronics), part: 0x6419, ver: 0x0) Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints <snip> File jlink.cfg:
> interface jlink
> <eof>
> File openocd.cfg:
> set WORKAREASIZE 0x40000
> source [find target/stm32f4x.cfg]
> <eof>
> (3) Then using 'newt debug xxx_boot' in another terminal type 'load' to program the Flash and begin debugging or just exit.
> (4) Then repeat using 'newt debug xxx_blinky' or 'newt debug xxx_slinky', etc.
> Needless to say this is an inconvenient process!
>
> Some observations:
> (1) I noticed that I get an assert() message coming from the function log_reboot_pkg_init() which was traced to the fcb_init() function returning rc = -7 (to do with bad MAGIC). I figured out this is because the circular Flash boot log can't be initialized if there is anything other than FF's at Flash location 0x8004000 - hence the need to erase the entire chip.
Yup. I’m thinking we should erase that area if it has unexpected data in it.
At the moment if fcb_init() backs out due to seeing unexpected magic in it,
and log_reboot_pkg_init() asserts.
> (2) Note by overriding slinky's default configuration to log reboots to flash shown below, I was able to get the console up and running ok:
> File syscfg.yml:
> # Package: apps/slinky
> syscfg.vals:
> # Log reboot messages to a flash circular buffer.
> REBOOT_LOG_FCB: 0
> LOG_FCB: 0
> <eof>
> (3) I'm assuming that the Flash memory mapping is probably correct. Actually this mapping originated from the existing STM32F407xx, which has up to 1M of on chip Flash so I believe the same memory map should work for 1M version of the STM32F427IG chip that I'm using.
I suspect that’s correct. I’m assuming here that the flash sector boundaries are the same on this model
are the same as they are on 407.
> File bsp.yml file:
> bsp.flash_map:
> areas:
> # System areas.
> FLASH_AREA_BOOTLOADER:
> device: 0
> offset: 0x08000000
> size: 16kB
> FLASH_AREA_IMAGE_0:
> device: 0
> offset: 0x08020000
> size: 384kB
> FLASH_AREA_IMAGE_1:
> device: 0
> offset: 0x08080000
> size: 384kB
> FLASH_AREA_IMAGE_SCRATCH:
> device: 0
> offset: 0x080e0000
> size: 128kB
>
> # User areas.
> FLASH_AREA_REBOOT_LOG:
> user_id: 0
> device: 0
> offset: 0x08004000
> size: 16kB
> FLASH_AREA_NFFS:
> user_id: 1
> device: 0
> offset: 0x08008000
> size: 32kB
> <eof>
> BTW Does anyone know why there is a 64K hole above the NFFS Flash area (ie. 0x80010000-0x8001FFFF) that isn't accounted for?
That is just unused by default. You can use it to stash logs, more config etc.
> (4) The SRAM size is a bit bigger so I adjusted the SRAM_SIZE from 128K to 192K in the bsp.h file.
>
> Am I missing something else? Any suggestions are welcome.
Linker scripts are the key for RAM size. I assume you meant define RAM_SIZE, not SRAM_SIZE?
This is used in hal_bsp to figure out the default memory areas to include in coredump, if ppl end up
using those.
>
> ALan
>
> -----Original Message-----
> From: Alan Graves [mailto:agraves@deltacontrols.com]
> Sent: Monday, March 06, 2017 5:29 PM
> To: dev@mynewt.incubator.apache.org
> Subject: RE: New STM32F427xx port
>
> Thx Fabio for those tips. I'll keep plugging away at it.
> ALan
>
> -----Original Message-----
> From: Fabio Utzig [mailto:utzig@utzig.org]
> Sent: Monday, March 06, 2017 4:42 PM
> To: dev@mynewt.incubator.apache.org
> Subject: Re: New STM32F427xx port
>
> Hi Alan,
>
> I recently created a port for the STM32F7xx, which is not complete due to some missing hal_ drivers, but I upgraded CMSIS to 4.3.0. PR is waiting to be merged:
>
> https://github.com/apache/incubator-mynewt-core/pull/179/
>
> And I used as base for the startup/etc files STM32Cube V1.6.0. My idea would be to upgrade all STM32Fx ports to that version, to at least have some tracking of what versions are being used, etc, otherwise everything is getting to be messy with lots of different ext files around.
>
> Anyway, at least two changes I remember having to do to the startup_*.s:
>
> 1) It jumps to "main" at the end of the Reset_Handler. You need to change it to jump to "_start".
> 2) There is already zeroing of the "bss" section, but you also need to add zeroing of "corebss".
>
> Of course the linker script also has to be updated accordingly (sections/labels that match).
>
> Cheers,
> Fabio Utzig
>
> On Mon, Mar 6, 2017, at 08:16 PM, Alan Graves wrote:
>> I've been working on what I thought was a simple port to this
>> architecture and have a problem with versions for the startup files.
>> If I understand the STM architecture directories correctly I was
>> expecting to simply swap out files used by the 'stm32f4discovery'
>> package (ie. V1.4, dated 09-Jul-2012):
>> hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
>> with this one needed by my port:
>> startup_stm32f427xx.s
>>
>> Unfortunately I found that the external CMSIS files located in this
>> directory are dated much newer (ie. V2.5.1, 28-June-2016):
>>
>> hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Source/
>> Templates/gcc/startup_stm32f407xx.s
>>
>> Naturally I assumed that this would be a straight forward port since
>> the microprocessor are very similar. Does anyone have the right
>> version of the startup file that I can use?
>>
>> Note that from what I can tell the include files being used by
>> 'stm32f4discovery' port are being mixed with an older startup file
>> version. Even though this appears to be working, I would suggest that
>> the current STM bsp be brought up to date to use the newest CMSIS
>> support as the global variables are quite a bit different. This would
>> save others from running into similar confusion and porting problems.
>>
>> ALan
RE: New STM32F427xx port
Posted by Alan Graves <ag...@deltacontrols.com>.
False alarm! The newt load and debug scripts are working now. I had an error in a .cfg file that was causing an openocd error...
ALan
-----Original Message-----
From: Alan Graves [mailto:agraves@deltacontrols.com]
Sent: Wednesday, March 08, 2017 3:12 PM
To: dev@mynewt.incubator.apache.org
Subject: RE: New STM32F427xx port
Wow finally the OS is running, at least under a J-Link debugger, however I'm having issues getting a 'newt load xxx_blinky' to work or even get 'xxx_blinky' operating without using the debugger.
Here is what I've had to do to get things kind of going:
(1) I discovered that I can muck about with other tools, namely IAR EWARM (under Windows) or JLinkExe (under Linux), to erase the entire MCU Flash memory. This is very important when running 'slinky'!
(2) I can also run 'openocd' from a terminal to establish a J-Link debugger connection first because the 'newt load xxx_boot' scripts fail to startup the openocd. I can't figure those blasted scripts out!
$ openocd -f /usr/share/openocd/scripts/interface/jlink.cfg -f openocd.cfg Open On-Chip Debugger 0.10.0+dev-00092-g77189db (2017-03-01-15:08) Licensed under GNU GPL v2 For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : No device selected, using first device.
Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46 Info : Hardware version: 8.00 Info : VTarget = 3.319 V Info : clock speed 2000 kHz Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4) Info : JTAG tap: stm32f4x.bs tap/device found: 0x06419041 (mfg: 0x020 (STMicroelectronics), part: 0x6419, ver: 0x0) Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints <snip> File jlink.cfg:
interface jlink
<eof>
File openocd.cfg:
set WORKAREASIZE 0x40000
source [find target/stm32f4x.cfg]
<eof>
(3) Then using 'newt debug xxx_boot' in another terminal type 'load' to program the Flash and begin debugging or just exit.
(4) Then repeat using 'newt debug xxx_blinky' or 'newt debug xxx_slinky', etc.
Needless to say this is an inconvenient process!
Some observations:
(1) I noticed that I get an assert() message coming from the function log_reboot_pkg_init() which was traced to the fcb_init() function returning rc = -7 (to do with bad MAGIC). I figured out this is because the circular Flash boot log can't be initialized if there is anything other than FF's at Flash location 0x8004000 - hence the need to erase the entire chip.
(2) Note by overriding slinky's default configuration to log reboots to flash shown below, I was able to get the console up and running ok:
File syscfg.yml:
# Package: apps/slinky
syscfg.vals:
# Log reboot messages to a flash circular buffer.
REBOOT_LOG_FCB: 0
LOG_FCB: 0
<eof>
(3) I'm assuming that the Flash memory mapping is probably correct. Actually this mapping originated from the existing STM32F407xx, which has up to 1M of on chip Flash so I believe the same memory map should work for 1M version of the STM32F427IG chip that I'm using.
File bsp.yml file:
bsp.flash_map:
areas:
# System areas.
FLASH_AREA_BOOTLOADER:
device: 0
offset: 0x08000000
size: 16kB
FLASH_AREA_IMAGE_0:
device: 0
offset: 0x08020000
size: 384kB
FLASH_AREA_IMAGE_1:
device: 0
offset: 0x08080000
size: 384kB
FLASH_AREA_IMAGE_SCRATCH:
device: 0
offset: 0x080e0000
size: 128kB
# User areas.
FLASH_AREA_REBOOT_LOG:
user_id: 0
device: 0
offset: 0x08004000
size: 16kB
FLASH_AREA_NFFS:
user_id: 1
device: 0
offset: 0x08008000
size: 32kB
<eof>
BTW Does anyone know why there is a 64K hole above the NFFS Flash area (ie. 0x80010000-0x8001FFFF) that isn't accounted for?
(4) The SRAM size is a bit bigger so I adjusted the SRAM_SIZE from 128K to 192K in the bsp.h file.
Am I missing something else? Any suggestions are welcome.
ALan
-----Original Message-----
From: Alan Graves [mailto:agraves@deltacontrols.com]
Sent: Monday, March 06, 2017 5:29 PM
To: dev@mynewt.incubator.apache.org
Subject: RE: New STM32F427xx port
Thx Fabio for those tips. I'll keep plugging away at it.
ALan
-----Original Message-----
From: Fabio Utzig [mailto:utzig@utzig.org]
Sent: Monday, March 06, 2017 4:42 PM
To: dev@mynewt.incubator.apache.org
Subject: Re: New STM32F427xx port
Hi Alan,
I recently created a port for the STM32F7xx, which is not complete due to some missing hal_ drivers, but I upgraded CMSIS to 4.3.0. PR is waiting to be merged:
https://github.com/apache/incubator-mynewt-core/pull/179/
And I used as base for the startup/etc files STM32Cube V1.6.0. My idea would be to upgrade all STM32Fx ports to that version, to at least have some tracking of what versions are being used, etc, otherwise everything is getting to be messy with lots of different ext files around.
Anyway, at least two changes I remember having to do to the startup_*.s:
1) It jumps to "main" at the end of the Reset_Handler. You need to change it to jump to "_start".
2) There is already zeroing of the "bss" section, but you also need to add zeroing of "corebss".
Of course the linker script also has to be updated accordingly (sections/labels that match).
Cheers,
Fabio Utzig
On Mon, Mar 6, 2017, at 08:16 PM, Alan Graves wrote:
> I've been working on what I thought was a simple port to this
> architecture and have a problem with versions for the startup files.
> If I understand the STM architecture directories correctly I was
> expecting to simply swap out files used by the 'stm32f4discovery'
> package (ie. V1.4, dated 09-Jul-2012):
> hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
> with this one needed by my port:
> startup_stm32f427xx.s
>
> Unfortunately I found that the external CMSIS files located in this
> directory are dated much newer (ie. V2.5.1, 28-June-2016):
>
> hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Source/
> Templates/gcc/startup_stm32f407xx.s
>
> Naturally I assumed that this would be a straight forward port since
> the microprocessor are very similar. Does anyone have the right
> version of the startup file that I can use?
>
> Note that from what I can tell the include files being used by
> 'stm32f4discovery' port are being mixed with an older startup file
> version. Even though this appears to be working, I would suggest that
> the current STM bsp be brought up to date to use the newest CMSIS
> support as the global variables are quite a bit different. This would
> save others from running into similar confusion and porting problems.
>
> ALan
RE: New STM32F427xx port
Posted by Alan Graves <ag...@deltacontrols.com>.
Wow finally the OS is running, at least under a J-Link debugger, however I'm having issues getting a 'newt load xxx_blinky' to work or even get 'xxx_blinky' operating without using the debugger.
Here is what I've had to do to get things kind of going:
(1) I discovered that I can muck about with other tools, namely IAR EWARM (under Windows) or JLinkExe (under Linux), to erase the entire MCU Flash memory. This is very important when running 'slinky'!
(2) I can also run 'openocd' from a terminal to establish a J-Link debugger connection first because the 'newt load xxx_boot' scripts fail to startup the openocd. I can't figure those blasted scripts out!
$ openocd -f /usr/share/openocd/scripts/interface/jlink.cfg -f openocd.cfg
Open On-Chip Debugger 0.10.0+dev-00092-g77189db (2017-03-01-15:08)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : No device selected, using first device.
Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46
Info : Hardware version: 8.00
Info : VTarget = 3.319 V
Info : clock speed 2000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06419041 (mfg: 0x020 (STMicroelectronics), part: 0x6419, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
<snip>
File jlink.cfg:
interface jlink
<eof>
File openocd.cfg:
set WORKAREASIZE 0x40000
source [find target/stm32f4x.cfg]
<eof>
(3) Then using 'newt debug xxx_boot' in another terminal type 'load' to program the Flash and begin debugging or just exit.
(4) Then repeat using 'newt debug xxx_blinky' or 'newt debug xxx_slinky', etc.
Needless to say this is an inconvenient process!
Some observations:
(1) I noticed that I get an assert() message coming from the function log_reboot_pkg_init() which was traced to the fcb_init() function returning rc = -7 (to do with bad MAGIC). I figured out this is because the circular Flash boot log can't be initialized if there is anything other than FF's at Flash location 0x8004000 - hence the need to erase the entire chip.
(2) Note by overriding slinky's default configuration to log reboots to flash shown below, I was able to get the console up and running ok:
File syscfg.yml:
# Package: apps/slinky
syscfg.vals:
# Log reboot messages to a flash circular buffer.
REBOOT_LOG_FCB: 0
LOG_FCB: 0
<eof>
(3) I'm assuming that the Flash memory mapping is probably correct. Actually this mapping originated from the existing STM32F407xx, which has up to 1M of on chip Flash so I believe the same memory map should work for 1M version of the STM32F427IG chip that I'm using.
File bsp.yml file:
bsp.flash_map:
areas:
# System areas.
FLASH_AREA_BOOTLOADER:
device: 0
offset: 0x08000000
size: 16kB
FLASH_AREA_IMAGE_0:
device: 0
offset: 0x08020000
size: 384kB
FLASH_AREA_IMAGE_1:
device: 0
offset: 0x08080000
size: 384kB
FLASH_AREA_IMAGE_SCRATCH:
device: 0
offset: 0x080e0000
size: 128kB
# User areas.
FLASH_AREA_REBOOT_LOG:
user_id: 0
device: 0
offset: 0x08004000
size: 16kB
FLASH_AREA_NFFS:
user_id: 1
device: 0
offset: 0x08008000
size: 32kB
<eof>
BTW Does anyone know why there is a 64K hole above the NFFS Flash area (ie. 0x80010000-0x8001FFFF) that isn't accounted for?
(4) The SRAM size is a bit bigger so I adjusted the SRAM_SIZE from 128K to 192K in the bsp.h file.
Am I missing something else? Any suggestions are welcome.
ALan
-----Original Message-----
From: Alan Graves [mailto:agraves@deltacontrols.com]
Sent: Monday, March 06, 2017 5:29 PM
To: dev@mynewt.incubator.apache.org
Subject: RE: New STM32F427xx port
Thx Fabio for those tips. I'll keep plugging away at it.
ALan
-----Original Message-----
From: Fabio Utzig [mailto:utzig@utzig.org]
Sent: Monday, March 06, 2017 4:42 PM
To: dev@mynewt.incubator.apache.org
Subject: Re: New STM32F427xx port
Hi Alan,
I recently created a port for the STM32F7xx, which is not complete due to some missing hal_ drivers, but I upgraded CMSIS to 4.3.0. PR is waiting to be merged:
https://github.com/apache/incubator-mynewt-core/pull/179/
And I used as base for the startup/etc files STM32Cube V1.6.0. My idea would be to upgrade all STM32Fx ports to that version, to at least have some tracking of what versions are being used, etc, otherwise everything is getting to be messy with lots of different ext files around.
Anyway, at least two changes I remember having to do to the startup_*.s:
1) It jumps to "main" at the end of the Reset_Handler. You need to change it to jump to "_start".
2) There is already zeroing of the "bss" section, but you also need to add zeroing of "corebss".
Of course the linker script also has to be updated accordingly (sections/labels that match).
Cheers,
Fabio Utzig
On Mon, Mar 6, 2017, at 08:16 PM, Alan Graves wrote:
> I've been working on what I thought was a simple port to this
> architecture and have a problem with versions for the startup files.
> If I understand the STM architecture directories correctly I was
> expecting to simply swap out files used by the 'stm32f4discovery'
> package (ie. V1.4, dated 09-Jul-2012):
> hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
> with this one needed by my port:
> startup_stm32f427xx.s
>
> Unfortunately I found that the external CMSIS files located in this
> directory are dated much newer (ie. V2.5.1, 28-June-2016):
>
> hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Source/
> Templates/gcc/startup_stm32f407xx.s
>
> Naturally I assumed that this would be a straight forward port since
> the microprocessor are very similar. Does anyone have the right
> version of the startup file that I can use?
>
> Note that from what I can tell the include files being used by
> 'stm32f4discovery' port are being mixed with an older startup file
> version. Even though this appears to be working, I would suggest that
> the current STM bsp be brought up to date to use the newest CMSIS
> support as the global variables are quite a bit different. This would
> save others from running into similar confusion and porting problems.
>
> ALan
RE: New STM32F427xx port
Posted by Alan Graves <ag...@deltacontrols.com>.
Thx Fabio for those tips. I'll keep plugging away at it.
ALan
-----Original Message-----
From: Fabio Utzig [mailto:utzig@utzig.org]
Sent: Monday, March 06, 2017 4:42 PM
To: dev@mynewt.incubator.apache.org
Subject: Re: New STM32F427xx port
Hi Alan,
I recently created a port for the STM32F7xx, which is not complete due to some missing hal_ drivers, but I upgraded CMSIS to 4.3.0. PR is waiting to be merged:
https://github.com/apache/incubator-mynewt-core/pull/179/
And I used as base for the startup/etc files STM32Cube V1.6.0. My idea would be to upgrade all STM32Fx ports to that version, to at least have some tracking of what versions are being used, etc, otherwise everything is getting to be messy with lots of different ext files around.
Anyway, at least two changes I remember having to do to the startup_*.s:
1) It jumps to "main" at the end of the Reset_Handler. You need to change it to jump to "_start".
2) There is already zeroing of the "bss" section, but you also need to add zeroing of "corebss".
Of course the linker script also has to be updated accordingly (sections/labels that match).
Cheers,
Fabio Utzig
On Mon, Mar 6, 2017, at 08:16 PM, Alan Graves wrote:
> I've been working on what I thought was a simple port to this
> architecture and have a problem with versions for the startup files.
> If I understand the STM architecture directories correctly I was
> expecting to simply swap out files used by the 'stm32f4discovery'
> package (ie. V1.4, dated 09-Jul-2012):
> hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
> with this one needed by my port:
> startup_stm32f427xx.s
>
> Unfortunately I found that the external CMSIS files located in this
> directory are dated much newer (ie. V2.5.1, 28-June-2016):
>
> hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Source/
> Templates/gcc/startup_stm32f407xx.s
>
> Naturally I assumed that this would be a straight forward port since
> the microprocessor are very similar. Does anyone have the right
> version of the startup file that I can use?
>
> Note that from what I can tell the include files being used by
> 'stm32f4discovery' port are being mixed with an older startup file
> version. Even though this appears to be working, I would suggest that
> the current STM bsp be brought up to date to use the newest CMSIS
> support as the global variables are quite a bit different. This would
> save others from running into similar confusion and porting problems.
>
> ALan
Re: New STM32F427xx port
Posted by Fabio Utzig <ut...@utzig.org>.
Hi Alan,
I recently created a port for the STM32F7xx, which is not complete due
to some missing hal_ drivers, but I upgraded CMSIS to 4.3.0. PR is
waiting to be merged:
https://github.com/apache/incubator-mynewt-core/pull/179/
And I used as base for the startup/etc files STM32Cube V1.6.0. My idea
would be to upgrade all STM32Fx ports to that version, to at least have
some tracking of what versions are being used, etc, otherwise everything
is getting to be messy with lots of different ext files around.
Anyway, at least two changes I remember having to do to the startup_*.s:
1) It jumps to "main" at the end of the Reset_Handler. You need to
change it to jump to "_start".
2) There is already zeroing of the "bss" section, but you also need to
add zeroing of "corebss".
Of course the linker script also has to be updated accordingly
(sections/labels that match).
Cheers,
Fabio Utzig
On Mon, Mar 6, 2017, at 08:16 PM, Alan Graves wrote:
> I've been working on what I thought was a simple port to this
> architecture and have a problem with versions for the startup files. If I
> understand the STM architecture directories correctly I was expecting to
> simply swap out files used by the 'stm32f4discovery' package (ie. V1.4,
> dated 09-Jul-2012):
> hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_stm32f407xx.s
> with this one needed by my port:
> startup_stm32f427xx.s
>
> Unfortunately I found that the external CMSIS files located in this
> directory are dated much newer (ie. V2.5.1, 28-June-2016):
> hw/mcu/stm/stm32f4xx/src/ext/Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc/startup_stm32f407xx.s
>
> Naturally I assumed that this would be a straight forward port since the
> microprocessor are very similar. Does anyone have the right version of
> the startup file that I can use?
>
> Note that from what I can tell the include files being used by
> 'stm32f4discovery' port are being mixed with an older startup file
> version. Even though this appears to be working, I would suggest that the
> current STM bsp be brought up to date to use the newest CMSIS support as
> the global variables are quite a bit different. This would save others
> from running into similar confusion and porting problems.
>
> ALan