Ok, there’s a bug there, caused by debug printfs. Probably my fault. There is a call to console_printf() in bootloader. apps/boot/boot.c, lines 120-121. Those should not be there. And they will crash nrf52 when building with BOOT_SERIAL set. Remove them, and you should be ok.
> On Sep 23, 2016, at 3:12 PM, marko kiiskila <[email protected]> wrote: > > >> On Sep 23, 2016, at 12:15 PM, Kevin Townsend <[email protected]> wrote: >> >> Hi Marko, >> >> Thanks for the reply ... I wasn't sure what to do with the console/stub >> dependency though ... where should this be set? > > You should remove the console/stub from apps/boot/pkg.yml. > libs/boot_serial needs console/full. > I imagine this step can be made automatic once the new sysconfig stuff is > brought in. > > As a side note; this warning seems to be harmless on my build, i.e. it does > pick up the full console, but I might > be just getting lucky. > >> >> # >> # Define BOOT_SERIAL in target features to include serial downloader. >> # And uncomment 'libs/console/stub' from pkg.deps. >> # >> >> This builds properly but when I flash the bootloader on an nRF52 with an >> app, the app doesn't start up, but disabling BOOT_SERIAL it runs fine, so >> I'm clearly defining the lib/console/stub dependency in the wrong place >> (clear because I'm getting conflict alerts to the console libs when I >> compile). >> > > Did you try running the bootloader under debugger? Maybe it actually stops to > wait for serial input? > I have to admit I have not tried this code on nrf52, but it should be > functional. > >> I had this in the target.yml file for the bootloader target, but that >> doesn't seem to be correct: >> >> target.deps: "@apache-mynewt-core/libs/console/stub” >> K. >> >> On 23/09/16 20:56, marko kiiskila wrote: >>> That all looks good. >>> boot_serial package is supposed to be small. >>> >>> —8<—cut-start— >>> [marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ newt target show >>> boot_mkr1000 >>> targets/boot_mkr1000 >>> app=@apache-mynewt-core/apps/boot >>> bsp=@mynewt-arduino-zero/hw/bsp/arduino_mkr1000 >>> build_profile=optimized >>> features=BOOT_SERIAL >>> —8<—cut end — >>> >>> Indeed, you need to add 3 defines to your BSP. For testing, I only added >>> those to Arduino MKR1000 BSP. As you’ve probably figured out, these are for >>> the pin to use, and whether you want that pin pulled up/down, and whether >>> to compare pin value against 0 or 1. >>> >>> —8< — cut start — >>> [marko@IsMyLaptop:~/src/incubator-mynewt-blinky]$ grep BOOT_SERIAL >>> repos/mynewt-arduino-zero/hw/bsp/arduino_mkr1000/include/bsp/bsp.h >>> #ifdef BOOT_SERIAL >>> #define BOOT_SERIAL_DETECT_PIN 43 >>> #define BOOT_SERIAL_DETECT_PIN_CFG GPIO_PULL_UP >>> #define BOOT_SERIAL_DETECT_PIN_VAL 0 >>> —8< — cut end — >>> I thought I sent an email about this, but maybe it was missing these >>> details. Sorry >>> about that. >>> >>> Now that we can take interrupts even without OS, the size of the bootloader >>> with >>> serial support could be made smaller. At the moment it still starts the OS, >>> while the >>> boot_serial stuff could just spin in a loop waiting for input. >>> That would be attractive here, because then you could have the bootloader >>> smaller >>> than 16k (looks like it’s really close for your BSP). >>> >>>> On Sep 23, 2016, at 11:22 AM, Kevin Townsend <[email protected]> wrote: >>>> >>>> Hi Sterling, >>>> >>>> I saw the note on the dependency, but is the target the right place to be >>>> adding the dep entry as follows: >>>> >>>> $ newt target set bootloader >>>> deps="@apache-mynewt-core/libs/console/stub" >>>> >>>> Adding the two missing defines at the BSP level for BOOT_SERIAL gets this >>>> building at least >>>> >>>> - BOOT_SERIAL_DETECT_PIN >>>> - BOOT_SERIAL_DETECT_PIN_CFG >>>> >>>> The size still seems reasonable to me (<32KB), though I haven't tested >>>> this yet to see if it's being built correctly and the warning is setting >>>> an alarm bell off for me, but I'll test shortly: >>>> >>>> $ newt size bootloader >>>> Warning: API conflict: console (libs/console/stub <-> libs/console/full) >>>> Warning: API conflict: console (libs/console/stub <-> libs/console/full) >>>> FLASH RAM >>>> 23 222 *fill* >>>> 2136 32 baselibc.a >>>> 330 2128 boot.a >>>> 1141 12 boot_serial.a >>>> 1717 1132 bootutil.a >>>> 64 0 cmsis-core.a >>>> 20 1 config.a >>>> 124 0 crt0.o >>>> 8 0 crti.o >>>> 16 0 crtn.o >>>> 640 512 feather52.a >>>> 983 196 full.a >>>> 634 8 hal.a >>>> 80 0 libg.a >>>> 1436 0 libgcc.a >>>> 1200 0 mbedtls.a >>>> 1837 40 nrf52xxx.a >>>> 3322 809 os.a >>>> 945 0 util.a >>>> >>>> objsize >>>> text data bss dec hex filename >>>> 16644 128 4532 21304 5338 >>>> bin/bootloader/apps/boot/boot.elf >>>> >>>> K. >>>> >>>> >>>> On 23/09/16 17:57, Sterling Hughes wrote: >>>>> Hi Kevin, >>>>> >>>>> I think (and I’ll let Marko chime in here), you can use the boot_serial >>>>> package to achieve this (apache-mynewt-core/libs/boot_serial.) >>>>> >>>>> It speaks the newtmgr protocol, but doesn’t require the shell task or an >>>>> image to be programmed. I think it will slightly explode the size of >>>>> your boot loader, but that shouldn’t be a huge issue on the NRF52. >>>>> >>>>> apps/boot/ has the following options. >>>>> >>>>> # >>>>> # Define BOOT_SERIAL in target features to include serial downloader. >>>>> # And uncomment 'libs/console/stub' from pkg.deps. >>>>> # >>>>> pkg.deps.BOOT_SERIAL.OVERWRITE: >>>>> - libs/console/full >>>>> - libs/boot_serial >>>>> pkg.cflags.BOOT_SERIAL: >>>>> - -DBOOT_SERIAL >>>>> >>>>> It’s (unfortunately) been awhile since I’ve tested this, but we’ll take a >>>>> look today and make sure it’s still functioning (it should be.) >>>>> >>>>> Sterling >>>>> >>>>> On 23 Sep 2016, at 2:46, Kevin Townsend wrote: >>>>> >>>>>> Hi Will (and company), >>>>>> >>>>>> Sorry to recycle an old thread, but I was just doing some testing with >>>>>> the bootloader on the latest release, and wanted to come back to the >>>>>> issue of having a purely serial option for flashing images in the >>>>>> bootloader. From my perspective there are a number of valid use cases >>>>>> around uploading an image on an empty device (other than the bootloader) >>>>>> over UART or USB CDC, but others may disagree. >>>>>> >>>>>> This would provide an inexpensive mechanism to debrick boards, for >>>>>> example, as well as a useful tool for production environments where you >>>>>> don´t have the financial or practical means to send a half dozen >>>>>> commercially licensed JLink to your assembly house or somewhere in China >>>>>> for testing then flashing. >>>>>> >>>>>> Being able to run something like this with ONLY the bootloader present >>>>>> would be a big plus I think: >>>>>> >>>>>> $ newtmgr -c serial image upload bin/bleuart/apps/bleuart/bleuart.elf.bin >>>>>> >>>>>> As things stand today, you can only do this (I think, please correct me >>>>>> if I´m wrong) if you already have a valid image flashed and shell >>>>>> support enabled for newtmgr. >>>>>> >>>>>> Is there an obstacle anyone can see about why this wouldn't be practical >>>>>> to implement with only the bootloader present? We've been focused on >>>>>> application level code and the peripheral side of nimble so I haven't >>>>>> looked at the bootloader code at all, but will have a look to try to get >>>>>> a better sense of the requirements here to use it with serial without >>>>>> any sort of shell support on the application side. >>>>>> >>>>>> K. >>>>>> >>>>>> On 08/06/16 23:59, will sanfilippo wrote: >>>>>>> +1 >>>>>>> >>>>>>> Guess that is my one cent opinion :-) Wouldnt be hard to do and is >>>>>>> definitely a handy option for a certain group of folks. BTW, and this >>>>>>> is a minor detail, I am not so much for polling a pin; the bootloader >>>>>>> can look at the serial port for a certain sequence of characters. If it >>>>>>> sees them it enters download mode. If it doesnt see anything it likes >>>>>>> after that (or doesnt see that sequence), it tries to boot an image. If >>>>>>> it cant, it just cycles back. If it boots a valid image, all good. If >>>>>>> it boots a bricked image, you just gotta power cycle it. Shouldnt >>>>>>> increase boot time too much (which is something to keep in mind imo). >>>>>>> >>>>>>>> On Jun 8, 2016, at 12:42 PM, marko kiiskila <[email protected]> wrote: >>>>>>>> >>>>>>>> I’m convinced that we should have an option for using standalone boot >>>>>>>> loader >>>>>>>> with which you can upload images. These are valid use cases. >>>>>>>> >>>>>>>> We should make that happen. >>>>>>>> >> >
