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:[email protected]] > Sent: Thursday, March 09, 2017 5:40 PM > To: dev <[email protected]> > 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 <[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/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 > > >
