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:[email protected]] Sent: Wednesday, March 08, 2017 4:14 PM To: dev <[email protected]> Subject: Re: New STM32F427xx port Cool, nice progress. I’ll comment more inline. > On Mar 8, 2017, at 4:00 PM, Alan Graves <[email protected]> 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:[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’! 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:[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
