Support for the other SAM D21/R21 chip variants

[Alex Albino]

I am working with the Arduino Zero bootloader to hopefully add support for the other Atmel SAM D21 and R21 chips (such as ATSAMD21E18A, and ATSAMR21E18A).

I noticed the boatloader currently expects a 32MHz clock. My plan is to see if the timer setup can be refactored to make the 32MHz clock setup optional (though it seems I will also need to look at the reset routines).

This way, I can potentially make bootloaders derived on the Arduino Zero, but having the 32MHz timer become optional.

I want to do this to make it easier for makers to develop with the Atmel SAM D21 and R21 line of chips - not just the larger ATSAMD21G18A.

If anyone has any suggestions (or you are already working on this), I would love to hear back.

[Mike]

It would appear that the specs for the Arduino.cc MKR1000 will have multiple clock speeds supported https://www.arduino.cc/en/Main/ArduinoMKR1000

This might not help now, but having the MKR1000 code might show how to have other SAMs supported?

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[William Westfield]

> I noticed the [Arduino zero] boatloader currently expects a 32MHz clock.

It does? Doesn’t the runtime reset the clock? It looks like the hardware has a 32.768kHz crystal, and the chip has a DFL and/or PLL that can generate nearly any clock frequency from any crystal value, and change this on-the-fly if desired… The bootloader can run at a completely different frequency, derived from a different source, than the main application, if you want.

BillW/WestfW

[Alex Albino]

...the 32MHz crystal isn't required to build an basic microcontroller circuit with the SAM D21/R21 line of chips. However, I noticed the Arduino Zero bootloader has timer set up routines that enable it 100% of the time (because it is for the Arduino Zero board, which has such a crystal attached).

I am talking about ArduinoCore-samd/bootloader/zero/board_init.c, line 54

...I was thinking surrounding some of the routines in this file w/ #ifdef/#else#endif blocks would allow us to use the Arduino Zero bootloader code, and supply different bits of code to support the same SAM D21/R21 chips without a 32MHz crystal. This is a preliminary thought, of course.

I would additionally add variants specific to each SAM D21/R21 variant (G, E, etc).

Currently, attempting to use the Arduino Zero bootloader on a board w/o a 32MHz  crystal will simply not begin program execution, as the first clock tick doesn't seem to occur.

[William Westfield]

> ...the 32MHz crystal isn't required to build an basic microcontroller circuit with the SAM D21/R21 line of chips.

32kHz. Kilohertz (standard “watch” crystal.)

> I am talking about ArduinoCore-samd/bootloader/zero/board_init.c, line 54

Interesting. That’s much different than the bootloader in the binary distribution (/packages/arduino/hardware/samd/1.6.2/bootloaders/zero/) I wonder which one is actually in use (if any. Since the zero has the eDBG chip on there, it could get by with no bootloader.)

In any case, there is similar code in /packages/arduino/hardware/samd/1.6.2/cores/arduino/startup.c, so changing the bootloader only is not sufficient.
In theory, you can test whether starting the 32kHz oscillator is successful by implementing some sort of timeout for :
> while ( (SYSCTRL->PCLKSR.reg & SYSCTRL_PCLKSR_XOSC32KRDY) == 0 )
> {
> /* Wait for oscillator stabilization */
> }
And then fall back to the internal 8MHz oscillator. Or something. I don’t see how you’d test for all possible clock setups, or even “cleanly” put them in conditional compilation. (although I guess that realistically, there are only four interesting setups: 32kHz crystal, “fast” crystal, external clock, and internal clock.)

BillW/WestfW

[Alex Albino]

Hahaha...you are correct. 32kHz, ...my apologies.

I have some Atmel examples working with the internal 8MHz oscillator (prescale set to 0) for the SAM R21 (ATSAMR21E18A). https://github.com/femtoio/samr21-xplained-pro

...but if I am not working with the correct bootloader source code, does anyone know where the correct one is at?

If I succeed, I want to be certain I am contributing correctly.

Thanks in advance.

- Alex

[Thibaut VIARD]

Hi,

I have provided some patches on the bootloader which are in mainline but integrated after the generation of samd package v1.6.2.

Next release will come with what you see in mainline.

The use of 32k external oscillator in bootloader bring a better stability of usb during sketch binary transfer.

If you don't intend to use bossa/usb, you can keep the setup clock configuration which is 1MHz on internal RC.
Otherwise, you may meet broken USB  transfers.

Besides that, if you don't intend to have an external 32kHz oscillator on your board, be careful on how you expect using it: an internal RC isn't as precise (ie has some jitter) as a real external one and may bring you issues while using some peripherals like usart, i2c and spi, depending on the components plugged to them. Obviously, these peripherals are less sensitive than USB.

Cheers,

T.

[Alex Albino]

Thanks Thibaut.

As I understood it, there should not be a problem with the SAM D21 USB while the main oscillator is 48MHz. The Atmel data sheet warns of USB problems, but it appears to apply when the main oscillator is below 48MHZ.

I am able to operate a bare SAM D21 board with only a 48MHz clock source and the recommended caps/resistors etc. Note, however, I have not tested extensively.

Updates via the BOSSA tool work without error.

Would you mind providing a link to your repository? I'd love to collaborate where possible.

Blink example (C source) for SAM D21
https://github.com/femtoio/femto-usb-blink-example/blob/master/README.md

EAGLE PCB files, OpenOCD config: https://github.com/femtoio/femto-usb

[Thibaut VIARD]

Hi Alex,

Almost everything I did has been merged by Cristian in main line: https://github.com/arduino/ArduinoCore-samd

My (closed) Pull Request is here: https://github.com/arduino/ArduinoCore-samd/pull/47

You may not have to duplicate the bootloader source code for your own variant. There are already some examples of 'custom' bootloaders based on Arduino Zero one with only a custom Makefile:
- https://github.com/ameltech/sme-arduino-core/tree/master/hardware/AMEL/samd/bootloaders/sme and also https://github.com/ameltech/sme-arduino-core/pull/15
- https://github.com/AtmelUniversityFrance/atmel-samd21-xpro-boardmanagermodule/tree/master/module/bootloaders

At the moment, only one customization is not possible regarding the serial port if a variant doesn't use the same SERCOM/pins as in Arduino Zero but I'm investigating on this.

You got me with your new repo, I was following the previous one (femtoduino) :-)

I was waiting for some code and variant description coming besides the board hardware design.

Tell me if can be of any help.

Cheers,

T.

[Alex Albino]

Thank you Thibaut,

For now, I am simply going to copy the Arduino Zero variant, and adjust the pins to work with the ATSAMD21E18A. The SAM-BA bootloader from Atmel works fine (I can upload sketches to the SAM D21 E chip just fine), so I can probably get a working barebones board w/ SAM-BA + the new ATSAMD21E18A board variant that I'm piecing together.

I'll report back with progress. Stay tuned. :-)

[Randy Ferrell]

Need help with layout I can help. Just decide what you want similar to pi zero?

[Alex Albino]

@all I have made my current progress available on my git fork ("atsamd21e18a_variant" branch)

...I've copied the Arduino Zero variant, and modified the pin description map, along with the header file. The debug and linker scripts have been left as-is.

https://github.com/femtoio/ArduinoCore-samd/tree/atsamd21e18a_variant

I'll test it out later today. Coincidentally, if anyone knows where I can find info on packaging/loading into my Arduino IDE, I would appreciate the info.

Thanks

[Alex Albino]

Status update: I am able to load sketches using the new "atsamd21e18a" variant.

I am currently attempting to figure if/how I can configure the Serial object to work w/ SerialUSB ...currently, it just makes my board unavailable over USB, so I'm obviously missing something. :-)

Fwiw, I am also making a simple node.js based server to serve a package JSON and tar.bz2 achive so I can have the Arduino IDE load my package archive from localhost:8080

Stay tuned!

- Alex Albino

[Alex Albino]

...meh... The benefits outweigh the costs. For future note, SAM D21/R21 designs that wish to use the Arduino Zero bootloader (or a portion thereof) should simply add a 32.768kHZ external clock.

I've updated my FemtoUSB design to r1.0.1 and will test my derivative work (Arduino Zero core, but with a different pin config in variant.h and variant.c)

...I'll report back w/ progress and updates. Stay tuned.

[Alex Albino]

SUCCESS!!!

I have a modified Arduino Zero core that works with the Atmel SAM D21 E variant.

See https://github.com/femtoio/ArduinoCore-samd/tree/atsamd21e18a_variant?files=1

I am able to create my own package JSON file, along w/ corresponding SHA-256 checksum, and host it locally using my femtoio/Arduino-LocalTestRepo node server.

...The femtoio/femto-usb (femto-usb-r1.0.1 branch) repo has an arduino example named "Serial_Hello".

A simple "Hello" is output every second to the Serial Window using SerialUSB.

See https://github.com/femtoio/femto-usb/tree/femto-usb-r1.0.1?files=1

...I am now waiting on PCBs to test USB Host mode w/ Arduino.

[Alex Albino]

...I wanted to express my sincere thanks to the Arduino developer community for their solid work on the Arduino Zero core.

I am especially grateful for the SerialUSB feature.

Is there a preferred way to contribute back to the Arduino developer community? Is code OK? (Should I send someone a six-pack of beer?)

- Alex

[David Mellis]

Awesome! I'm excited about the SAMD21 E variant because the TQFP package could be good for milled boards (you can do 0.8 mm pitch w/ a 1/64" end mill). 

Have you looked into distributing the SAMD21E18 support as a third-party hardware package (i.e. via the boards manager)? It looks like you should be able to just distribute your boards.txt and variant files and point to the standard SAMD core.

[Alex Albino]

Hi David!

Yes, I have a customized board package based on the Arduino Zero core (bootloader is left as-is).

..I just don't have anywhere to deploy/host the generated package with an HTTPS connection yet. Working on it.

See https://github.com/femtoio/ArduinoCore-samd/tree/atsamd21e18a_variant?files=1

- Alex

[David Mellis]

Cool... you might want to omit the cores and bootloader from the package, so that you don't have to keep up with changes to the main core and boot loaders. Also, maybe GitHub pages is an option for hosting the releases? 

[Alex Albino]

David - Ah OK cool. I'll try digging around to see how I can configure my package accordingly and only the necessary files.

I am going to try hosting my package archive and JSON via github pages, thanks for the suggestion. :-)

- Alex

[Massimo Banzi]

quick tip

if your Json file is stored in a github repo you can use https://rawgit.com/ to "serves raw files directly from GitHub with proper Content-Type headers.”

it’s free and easy, just follow the instructions on the homepage.

so you don’t have to create a github page just for that

m

[Alex Albino]

Massimo - Ah ok cool. I'll give that a try too then. :-)

- Alex

[Thibaut VIARD]

Hi Alex,

At the moment, i serve my packages using github releases service and it works fine.

I didn't know about rawgit and will take a look at it. Thanks Massimo for the hint.

It may not be an option if the package files have to be in the git repo, contrary to github release which leaves the repo free of build results.

Cheers,

Thibaut

[Alex Albino]

Well, I now have hourly releases of the Atmel ATSAMD21E18A core work available. See the hourly build instructions at: https://github.com/femtoio/ArduinoCore-atsamd21e18a/tree/atsamd21e18a_variant

...ended up just hosting on one of my own servers. Should be OK for development.

- Alex

[Alex Albino]

Ok, now that the SAM D21 E variant is out of the way, I'm moving on to the SAM R21 (E variant)...

@Thibaut I love the use of a Makefile! It's incredibly convenient. I have forked the git repo at https://github.com/AtmelUniversityFrance/atmel-samd21-xpro-boardmanagermodule

I noticed, however, the chip expected is the SAM R21 G variant. The G variant has pins PA00 and PA01 available for XOSC32 ...however the SAM R21 E variant does not have those pins. It uses a 48MHz crystal clock source for XOSC on pins PA14 and PA15, and the XOSCRF clock source on the XTAL1 and XTAL2 pins.

Therefore, the SAM R21 E variant requires a modified startup (and hence modified Arduino Zero core) that will set up all internal clocks without a 32.768KHz clock source.

...I may have misunderstood something. Either way, I'd love to hear back with suggestions for the SAM R21 E.

 - Alex

[Thibaut VIARD]

Alex, are you really sure r21e doesn't have any pin for osc32?

I don't have the datasheet in front of me but i feel weird about this point as this is the basis of the device functionality

T.

[Alex Albino]

@Thibaut

From what I read, PA00 and PA01 (available only on the G variant) are used as the pins to a 32.768KHz clock source.

The E variant does not appear to have PA00 and PA01, nor does the datasheet mention any other pins for a 32KHz clock source on the E variant.

Perhaps I missed something in the data sheet?

- Alex

[Alex Albino]

@Thibaut 

Ok, upon further inspection, it seems the SAM R21 E may in fact have an internal 32.768KHz oscillator instead (See section 15.2 "Features")

However, See also Section 44.6.3 "External Real Time Oscillator". No external RTC oscillator available.

SAM R21 oscillator (not available in SAMR21E) is optimized for very low power consumption, hence close attention
should be made when selecting crystals, see Table 44-6 for maximum ESR recommendations on 9pF and 12.5pF
crystals .

[Peter Feerick]

lol... if it helps, on page 4 of the Atmel SAM21 datasheet[1] - in the configuration summary - it says for the '32.768kHz crystal oscillator (XOSC32K)' YES for R21G, and NO for R21E, and then in the next row under 'Oscillators' you have the option of the 32.768kHz internal oscillator (OSC32K) for both. So as you said Alex, no external 32.768 osc on the R21E, but both could be configured to use the internal one instead. 

btw, that is 45.6.3... 44 didn't do much for me ;)

That's my take on that after a quick look at the datasheet. 

Pete

---

[1] http://www.atmel.com/images/atmel-42223-sam-r21_datasheet.pdf

Peter Feerick
BIT, BLDes CQU

[Alex Albino]

@Peter

...I suspect the discrepancy regarding data sheet section numbers is due to me using a slightly older data sheet PDF. Sorry about that.

Ok, I guess the next logical step is to have the Arduino Zero core for SAM R21 E variant use the internal 32.768KHz clock source instead. I'll give it a go.

- Alex

[Thibaut VIARD]

Hi,

This is where i would suggest to move the startup file to the variant folder instead of keeping it in the core api.

It came naturally to me while experimenting here: https://github.com/aethaniel/ExperimentalCore-sam

[Alex Albino]

@Thibaut Thanks for the heads up.

I'll report back w/ progress over the next few days. Stay tuned!

[Alex Albino]

K, modified atmel-samd21-xpros Arduino core from AtmelUniversity-France repo. I'm still not too familiar with it.

I appear to have mis-configured (or not configured) something.

/home/aalbino/.arduino15/packages/arduino/hardware/samd/1.6.3/cores/arduino/wiring.c: In function 'init':
/home/aalbino/.arduino15/packages/arduino/hardware/samd/1.6.3/cores/arduino/wiring.c:82:41: error: 'PM_APBCMASK_DAC' undeclared (first use in this function)
   PM->APBCMASK.reg |= PM_APBCMASK_ADC | PM_APBCMASK_DAC ;
                                         ^
/home/aalbino/.arduino15/packages/arduino/hardware/samd/1.6.3/cores/arduino/wiring.c:82:41: note: each undeclared identifier is reported only once for each function it appears in
/home/aalbino/.arduino15/packages/arduino/hardware/samd/1.6.3/cores/arduino/wiring.c:122:11: error: 'DAC' undeclared (first use in this function)
   while ( DAC->STATUS.bit.SYNCBUSY == 1 ); // Wait for synchronization of registers between the clock domains
           ^
/home/aalbino/.arduino15/packages/arduino/hardware/samd/1.6.3/cores/arduino/wiring.c:123:20: error: 'DAC_CTRLB_REFSEL_AVCC' undeclared (first use in this function)
   DAC->CTRLB.reg = DAC_CTRLB_REFSEL_AVCC | // Using the 3.3V reference
                    ^
/home/aalbino/.arduino15/packages/arduino/hardware/samd/1.6.3/cores/arduino/wiring.c:124:20: error: 'DAC_CTRLB_EOEN' undeclared (first use in this function)
                    DAC_CTRLB_EOEN ;        // External Output Enable (Vout)
                    ^
exit status 1
Error compiling.

...I don't know if there is an DAC/ADC pin on the E variant. The G variant has ADC pin on PA04 (which doesn't exist on the E variant).

Guess I'll keep researching and testing. If anyone has suggestions, I'd love to hear them. :-)

 - Alex

[Alex Albino]

Confirmed - There is no Digital-to-Analog Converter (DAC) on the SAM R21 chips (regardless of variant). See the table at section 1, "Configuration Summary". Hence, the CMSIS (4.0.0-atmel) library for samr21 does not have PM_APBCMASK_DAC defined. It appears wiring.c in the arduino core (for the SAM D21 chips) simply assumes a DAC is available and attempts to use PM_APBMASK_DAC during clock setup.

/home/aalbino/.arduino15/packages/arduino/hardware/samd/1.6.3/cores/arduino/wiring.c: In function 'init':
/home/aalbino/.arduino15/packages/arduino/hardware/samd/1.6.3/cores/arduino/wiring.c:82:41: error: 'PM_APBCMASK_DAC' undeclared (first use in this function)
   PM->APBCMASK.reg |= PM_APBCMASK_ADC | PM_APBCMASK_DAC ;

@Thibaut I uncommented the SAM R21 board.txt configs, and tried working with those. I currently have to use the included SAM D21 bootloader, as the other boards (SAM W, SAM R) simply have a "Makefile" which fail to build on my machine. 

Creating build folder
mkdir build
make: *** No rule to make target 'build/board_driver_led.o', needed by 'samd21_sam_ba.elf'.  Stop.

I'd like to make DAC setup optional. The quickest way for me to do so is to wrap the relevant code in wiring.c using "If not defined" #ifndef blocks, so that it is always included, unless I define something like "NO_DAC" ...however, making a direct modification to the arduino core for this feels like a kludge. I'll go look at the Arduino core documentation and see if maybe there's a better way.

- Alex

[Thibaut VIARD]

Hi Alex,
I didn't have time yet to finish and publish the samr21 variant. That's why you met some issues.
I'm in business trip at the moment and unable to fix quickly.
Sorry for inconvenience.

T.

[Alex Albino]

@Thibaut - Ah ok, no worries. I modified a copy of the arduino core locally. I added #ifdef and #ifndef blocks appropriately to make DAC setup optional.

I made my own SAMR21 USB header (based on the SAMD21 USB header file) to compensate for differences in structures between SAM D21 and SAM R21.

I've also modified the startup file to use the internal 32.768KHz source for clock 1. It compiles, but doesn't seem to start up - so I'll keep messing with it until it works :-)

- Alex

[Alex Albino]

It seems I will need to step through start up and see why my modified copy of the zero bootloader is halting w/ segfaults...

Uploading a plain samd21e18a sam-ba bootloader from Atmel works fine.

Guess I can comment out everything but the most essential parts and start un-commenting stuff a little at a time to see what is causing segfaults.

On a related note, the segfaults are what appears to lock up the chip, preventing subsequent bootloader burns until the SAM ICE debugger + chip is powered off and on again.

- Alex

[Alex Albino]

I've (mostly) gotten the SAM R21 E working... Except for a minor issue with DLLFP48 closed loop configuration. ...I'll swap out crystals to assert I'm using 48MHz crystals on the XIN/XOUT pins and try again in the AM. I may have to try open loop mode. I'm not particularly happy about using the internal 32KHz clock source instead of an external one, but if it works, it works.

I've heavily modified my variant's usb related setup (never mind my previous comments on the .vec property, I was wrong)

Thankfully, I'm able to step through execution and see where the code is hanging (Eclipse + GNU ARM Eclipse tools)

Stay tuned.
- Alex

[Alex Albino]

...ok, I've figured out clock startup settings. It turns out (after reading the SAM R21 datasheet once more) that the XOSC inputs go from 0.4 to 32MHz, not 48MHz as I had erroneously thought. DFLL and FDLL clock setup can still happen, generating 48MHz and 96MHz clocks internally. The internal OSC32K clock can be enabled to generate 32.768KHz.

I referenced the SAM R21 XPlained Pro schematic and noticed a 12MHz crystal. I have ordered a small quantity of replacement crystals and will retry USB CDC operations in a few days.

Sincerely,

Alex Albino

[Alex Albino]

I DID IT!!!

Arduino bootloader for SAM R21E (the chip on my open-source FemtoBeacon)

https://youtu.be/_HiI5YkNh-k

Code is available here:

https://github.com/femtoio/ArduinoCore-atsamd21e18a/tree/atsamd21e18a_variant?files=1

Sincerely,

Alex Albino

[q2dg2b .]

Thanks a lot! Congratulations!

Maybe I say a sillyness, but could be possible to integrate this new core into Boards Manager as a "3rd party core"??

[Alex Albino]

It is. See the femtoIO github repo for ArduinoCore-atsamd21e18 ...I've simply included the SAM R21E18A variant along with the SAM D21E18A variant.

[Alex Albino]

Is anyone on the Arduino team still handling the BOSSA repository? I've had submitted a pull request to increment the bootloader size setting (should have been 0x2000, not 0x1000), fixing the Arduino sketch upload issues encountered by SAM R21 chip folks.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

[Cristian Maglie]

Il 29/08/2016 21:51, Alex Albino ha scritto:
> Is anyone on the Arduino team still handling the BOSSA repository? I've
> had submitted a pull request to increment the bootloader size setting
> (should have been 0x2000, not 0x1000), fixing the Arduino sketch upload
> issues encountered by SAM R21 chip folks.

Hi Alex,

I made a round of PR-merge on BOSSA repo (I've bossac on my todo list
later this week, but I've anticipated a bit).
Two bigger PR #21 and #7 remains, they require more testing (in
particular the cpu auto-detection part) and a bit of conflicts-edit.
Hope to make before next release.

I'm also trying to converge all forks
https://github.com/shumatech/BOSSA/issues/27, let's see how it goes.
C


--
Cristian Maglie <c.ma...@arduino.cc>

[Alex Albino]

Thank you Cristian! I appreciate your help. :-)

[Alex Albino]

Cristian - will there be a version bump that includes the latest BOSSA updates? (Currently, BOSSA is "1.6.1-arduino")

I tried downloading the latest Arduino IDE, Arduino Zero core/bootloader, ...but it seems I ended up w/ an older version of BOSSA.

Thank you for your help, I greatly appreciate it.

- Alex