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 <[email protected]> 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:[email protected]] > Sent: Thursday, March 09, 2017 4:45 PM > To: [email protected] > 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:[email protected]] > Sent: Wednesday, March 08, 2017 5:23 PM > To: [email protected] > 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:[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 >
