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:[email protected]] Sent: Wednesday, March 08, 2017 3:12 PM To: [email protected] 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:[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
