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:[email protected]]
Sent: Monday, March 06, 2017 5:29 PM
To: [email protected]
Subject: RE: New STM32F427xx port
Thx Fabio for those tips. I'll keep plugging away at it.
ALan
-----Original Message-----
From: Fabio Utzig [mailto:[email protected]]
Sent: Monday, March 06, 2017 4:42 PM
To: [email protected]
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
