Arduino Due vs Mac

Arduino Due vs Mac

[Simon Wright]

I'm trying to get my ARTS running on a Due, but have come across a huge
stumbling block in that I can't use the Bossa tool (or its command-line
equivalents) to upload the built binary to the target board from the
Mac.

There are several different versions of bossa, some of which recognise
the Due, most of which try to open the usb-serial connection at too high
a baud rate; but none will upload.

The Arduino application for the Mac works fine, but I really don't want
to write tiny programs in C in a tiny window!

I've attempted to write my own uploader, which is very frustrating (the
Atmel documentation is quite misleading in parts, and the board's
behaviour seems inconsistent, and the only sure answer seems to be to
understand the Bossa (C++) and Arduino (Java) code, baffling).

Do others have Due vs Mac problems, or is it that I managed to buy a
duff board?

Re: Arduino Due vs Mac

[Bob Duff]

Simon Wright <simon@pushface.org> writes:

> Do others have Due vs Mac problems, or is it that I managed to buy a
> duff board?

I don't sell boards.  I'm a software guy.  ;-)

- Bob

Re: Arduino Due vs Mac

[Simon Wright]

Bob Duff <bobduff@theworld.com> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> Do others have Due vs Mac problems, or is it that I managed to buy a
>> duff board?
>
> I don't sell boards.  I'm a software guy.  ;-)

I did wonder as I wrote. I thought the subject wouldn't attract your
attention!

Re: Arduino Due vs Mac

[Tero Koskinen]

6.7.2015, 19:17, Simon Wright kirjoitti:
> I'm trying to get my ARTS running on a Due, but have come across a huge
> stumbling block in that I can't use the Bossa tool (or its command-line
> equivalents) to upload the built binary to the target board from the
> Mac.
>
> There are several different versions of bossa, some of which recognise
> the Due, most of which try to open the usb-serial connection at too high
> a baud rate; but none will upload.
>
> The Arduino application for the Mac works fine, but I really don't want
> to write tiny programs in C in a tiny window!
>
> I've attempted to write my own uploader, which is very frustrating (the
> Atmel documentation is quite misleading in parts, and the board's
> behaviour seems inconsistent, and the only sure answer seems to be to
> understand the Bossa (C++) and Arduino (Java) code, baffling).
>
> Do others have Due vs Mac problems, or is it that I managed to buy a
> duff board?

Instead of using bossa, buy yourself a real JTAG adapter
(Segger JLink, etc.). If you at some point change to a different
ARM Cortex-M MCU, same JTAG adapter continues to work with it
also (unless you buy some very cheap vendor-specific JTAG).

Yours,
  Tero

Re: Arduino Due vs Mac

[Simon Wright]

Tero Koskinen <tero.koskinen@iki.fi> writes:

> Instead of using bossa, buy yourself a real JTAG adapter (Segger
> JLink, etc.). If you at some point change to a different ARM Cortex-M
> MCU, same JTAG adapter continues to work with it also (unless you buy
> some very cheap vendor-specific JTAG).

That would be the next step. Indeed, without JTAG I don't see how anyone
programs the Due, because of total absence of debug facilities; and it
does add considerably to the price (not that I can't afford it, just
seems a bit much for the hobbyist market). You're talking about
something like 3 times the cost of an STM32F4 Disco board, which has the
STLINK interface on-board and a straightforward and free software
solution for gdb; things stop, ^C, get a traceback from
last_chance_handler, on to the next problem.

Re: Arduino Due vs Mac

[darek]

On Monday, 6 July 2015 23:07:59 UTC+2, Simon Wright  wrote:
> Tero Koskinen  writes:
> 
> > Instead of using bossa, buy yourself a real JTAG adapter (Segger
> > JLink, etc.). If you at some point change to a different ARM Cortex-M
> > MCU, same JTAG adapter continues to work with it also (unless you buy
> > some very cheap vendor-specific JTAG).
> 
> That would be the next step. Indeed, without JTAG I don't see how anyone
> programs the Due, because of total absence of debug facilities; and it
> does add considerably to the price (not that I can't afford it, just
> seems a bit much for the hobbyist market). You're talking about
> something like 3 times the cost of an STM32F4 Disco board, which has the
> STLINK interface on-board and a straightforward and free software
> solution for gdb; things stop, ^C, get a traceback from
> last_chance_handler, on to the next problem.

For my hobby projects (SDR) at home I got this one (non-commercial use): 
  https://www.segger.com/j-link-edu.html
Together with the Olimex board :
  https://www.olimex.com/Products/ARM/ST/STM32-H407/open-source-hardware  and
a hobbyist version of the CrossWorks (http://www.rowley.co.uk/arm/) environment works very well. I know, its C but I had to start somewhere :). 
Again this is not Ada but it is worth checking:   http://www.mpeforth.com/xc7.htm#versions and  http://www.forth.com/embedded/swiftx-embedded-systems-14.html


Cheers,
  Darek 

Re: Arduino Due vs Mac

[Simon Wright]

darek <darek.maksimiuk@gmail.com> writes:

> On Monday, 6 July 2015 23:07:59 UTC+2, Simon Wright  wrote:
>> Tero Koskinen  writes:
>> 
>> > Instead of using bossa, buy yourself a real JTAG adapter (Segger
>> > JLink, etc.). If you at some point change to a different ARM Cortex-M
>> > MCU, same JTAG adapter continues to work with it also (unless you buy
>> > some very cheap vendor-specific JTAG).
>> 
>> That would be the next step. Indeed, without JTAG I don't see how
>> anyone programs the Due, because of total absence of debug
>> facilities; and it does add considerably to the price (not that I
>> can't afford it, just seems a bit much for the hobbyist
>> market). You're talking about something like 3 times the cost of an
>> STM32F4 Disco board, which has the STLINK interface on-board and a
>> straightforward and free software solution for gdb; things stop, ^C,
>> get a traceback from last_chance_handler, on to the next problem.
>
> For my hobby projects (SDR) at home I got this one (non-commercial use): 
>   https://www.segger.com/j-link-edu.html
> Together with the Olimex board :
>   https://www.olimex.com/Products/ARM/ST/STM32-H407/open-source-hardware  and
> a hobbyist version of the CrossWorks (http://www.rowley.co.uk/arm/)
> environment works very well. I know, its C but I had to start
> somewhere :).
> Again this is not Ada but it is worth checking:
> http://www.mpeforth.com/xc7.htm#versions and
> http://www.forth.com/embedded/swiftx-embedded-systems-14.html

I'm looking at the Segger EDU version and the Olimex connector (a tenth
the cost of the Segger version!)

Re: Arduino Due vs Mac

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> darek <darek.maksimiuk@gmail.com> writes:
>
>> On Monday, 6 July 2015 23:07:59 UTC+2, Simon Wright  wrote:
>>> Tero Koskinen  writes:
>>> 
>>> > Instead of using bossa, buy yourself a real JTAG adapter (Segger
>>> > JLink, etc.). If you at some point change to a different ARM Cortex-M
>>> > MCU, same JTAG adapter continues to work with it also (unless you buy
>>> > some very cheap vendor-specific JTAG).
>>> 
>>> That would be the next step. Indeed, without JTAG I don't see how
>>> anyone programs the Due, because of total absence of debug
>>> facilities; and it does add considerably to the price (not that I
>>> can't afford it, just seems a bit much for the hobbyist
>>> market). You're talking about something like 3 times the cost of an
>>> STM32F4 Disco board, which has the STLINK interface on-board and a
>>> straightforward and free software solution for gdb; things stop, ^C,
>>> get a traceback from last_chance_handler, on to the next problem.
>>
>> For my hobby projects (SDR) at home I got this one (non-commercial use): 
>>   https://www.segger.com/j-link-edu.html
>> Together with the Olimex board :
>>   https://www.olimex.com/Products/ARM/ST/STM32-H407/open-source-hardware  and
>> a hobbyist version of the CrossWorks (http://www.rowley.co.uk/arm/)
>> environment works very well. I know, its C but I had to start
>> somewhere :).
>> Again this is not Ada but it is worth checking:
>> http://www.mpeforth.com/xc7.htm#versions and
>> http://www.forth.com/embedded/swiftx-embedded-systems-14.html
>
> I'm looking at the Segger EDU version and the Olimex connector (a tenth
> the cost of the Segger version!)

Works just fine. I spent a lot of time looking at the 10-pin end of the
Olimex connector; the red side of the cable, which I believe means pin 1
is at that end, goes to the inboard end of the JTAG connector.

I run the GDB server with

$ jlinkgdbserver \
    -device ATSAM3X8E \
    -endian little \
    -if jtag \
    -localhostonly \
    -halt

(-if swd works too).

Re: Arduino Due vs Mac

[darek]

On Saturday, 11 July 2015 15:35:48 UTC+2, Simon Wright  wrote:
> Simon Wright writes:
> 
> > darek writes:
> >
> >> On Monday, 6 July 2015 23:07:59 UTC+2, Simon Wright  wrote:
> >>> Tero Koskinen  writes:
> >>> 
> >>> > Instead of using bossa, buy yourself a real JTAG adapter (Segger
> >>> > JLink, etc.). If you at some point change to a different ARM Cortex-M
> >>> > MCU, same JTAG adapter continues to work with it also (unless you buy
> >>> > some very cheap vendor-specific JTAG).
> >>> 
> >>> That would be the next step. Indeed, without JTAG I don't see how
> >>> anyone programs the Due, because of total absence of debug
> >>> facilities; and it does add considerably to the price (not that I
> >>> can't afford it, just seems a bit much for the hobbyist
> >>> market). You're talking about something like 3 times the cost of an
> >>> STM32F4 Disco board, which has the STLINK interface on-board and a
> >>> straightforward and free software solution for gdb; things stop, ^C,
> >>> get a traceback from last_chance_handler, on to the next problem.
> >>
> >> For my hobby projects (SDR) at home I got this one (non-commercial use): 
> >>   https://www.segger.com/j-link-edu.html
> >> Together with the Olimex board :
> >>   https://www.olimex.com/Products/ARM/ST/STM32-H407/open-source-hardware  and
> >> a hobbyist version of the CrossWorks (http://www.rowley.co.uk/arm/)
> >> environment works very well. I know, its C but I had to start
> >> somewhere :).
> >> Again this is not Ada but it is worth checking:
> >> http://www.mpeforth.com/xc7.htm#versions and
> >> http://www.forth.com/embedded/swiftx-embedded-systems-14.html
> >
> > I'm looking at the Segger EDU version and the Olimex connector (a tenth
> > the cost of the Segger version!)
> 
> Works just fine. I spent a lot of time looking at the 10-pin end of the
> Olimex connector; the red side of the cable, which I believe means pin 1
> is at that end, goes to the inboard end of the JTAG connector.
> 
> I run the GDB server with
> 
> $ jlinkgdbserver \
>     -device ATSAM3X8E \
>     -endian little \
>     -if jtag \
>     -localhostonly \
>     -halt
> 
> (-if swd works too).

Simon, 
 if it helps the doc for the Olimex board is here:https://www.olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407.pdf

Cheers,
  Darek 
  

Re: Arduino Due vs Mac

[Maciej Sobczak]

> I'm trying to get my ARTS running on a Due, but have come across a huge
> stumbling block in that I can't use the Bossa tool (or its command-line
> equivalents) to upload the built binary to the target board from the
> Mac.

Get the Arduino IDE and use the bossac tool that is part of it.
You should be able to upload any binary to the Arduino Due like this:

$ bossac -e -w -v -U true -p tty.usbmodemfd131 -b program.bin

Note: the USB device is a bit unpredictable, it might be tty.usbmodemfd141 or something - I had to check the availability of this special file name under /dev before every upload and use the actual name that was there.

> The Arduino application for the Mac works fine, but I really don't want
> to write tiny programs in C in a tiny window!

You can make that window bigger, too. ;-)

> Do others have Due vs Mac problems, or is it that I managed to buy a
> duff board?

I have used Due with a Mac myself. For a complete picture, I have compiled programs on RaspberryPi, but uploaded to Due from a Mac. No problems apart from unpredictable USB device name, as described above. It *might* be a broken board as well, but if it works fine with the Arduino IDE, then try with the bossac tool from the IDE.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Arduino Due vs Mac

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

>> I'm trying to get my ARTS running on a Due, but have come across a huge
>> stumbling block in that I can't use the Bossa tool (or its command-line
>> equivalents) to upload the built binary to the target board from the
>> Mac.
>
> Get the Arduino IDE and use the bossac tool that is part of it.

I don't see that? (that is, I downloaded the Arduino IDE and there's no
file called bossa* there at all).

What I did do is look again at https://github.com/shumatech/BOSSA.git
and **check out the 'arduino' branch** (and compile with clang, not
GCC!)

> You should be able to upload any binary to the Arduino Due like this:
>
> $ bossac -e -w -v -U true -p tty.usbmodemfd131 -b program.bin
>
> Note: the USB device is a bit unpredictable, it might be
> tty.usbmodemfd141 or something - I had to check the availability of
> this special file name under /dev before every upload and use the
> actual name that was there.

If I leave out -U and -p this works (after a long pause while it scans
through /dev/cu.Bluetooth- devices before finding /dev/cu.usbmodem1411
(this seems stable for the Due programming port on the USB port nearer
the front of the Macbook)).

Now I have to find out why I'm getting 'Floating point exception: 8",
but this is a huge improvement!

Re: Arduino Due vs Mac

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Maciej Sobczak <see.my.homepage@gmail.com> writes:
>
> What I did do is look again at https://github.com/shumatech/BOSSA.git
> and **check out the 'arduino' branch** (and compile with clang, not
> GCC!)
>
>> You should be able to upload any binary to the Arduino Due like this:
>>
>> $ bossac -e -w -v -U true -p tty.usbmodemfd131 -b program.bin
>>
>> Note: the USB device is a bit unpredictable, it might be
>> tty.usbmodemfd141 or something - I had to check the availability of
>> this special file name under /dev before every upload and use the
>> actual name that was there.
>
> If I leave out -U and -p this works (after a long pause while it scans
> through /dev/cu.Bluetooth- devices before finding /dev/cu.usbmodem1411
> (this seems stable for the Due programming port on the USB port nearer
> the front of the Macbook)).
>
> Now I have to find out why I'm getting 'Floating point exception: 8",
> but this is a huge improvement!

Turned out to be an integer division by zero if the number of Flash
pages to be written or verified was less than 10.

Now progressing to the point of having a blinking LED!!

As a matter of interest, I was able to write a simple program
initialization in Ada which, with minimal cooperation from the linker
script, lets me use gprbuild.

The linker script starts

   ENTRY(program_initialization)
   MEMORY
   {
       flash (RX)  : ORIGIN = 0x00080000, LENGTH = 512K
       sram (RWX)  : ORIGIN = 0x20070000, LENGTH = 96K
   }
   SECTIONS
   {
       .isr_vector :
       {
           . = ALIGN(4);
           LONG(_estack)
           LONG(program_initialization + 1)
           FILL(0)
           KEEP(*(.isr_vector))
       } > flash

       .text 0x00080100:

startup.ads:

   pragma Restrictions (No_Elaboration_Code);
   package Startup is
      procedure Program_Initialization
      with
        Export,
        Convention => C,
        External_Name => "program_initialization",
        No_Return;
   end Startup;

startup.adb:

   with System.Storage_Elements;
   package body Startup is

      --  Generated by gnatbind.
      procedure Main
      with
        Import,
        Convention => C,
        External_Name => "main",
        No_Return;

      procedure Program_Initialization is
         --  The following symbols are set up in the linker script:
         --
         --  _sidata: the start of read/write data in Flash, to be copied
         --           to SRAM
         --  _sdata:  where read/write data is to be copied to
         --  _edata: the first address after read/write data in SRAM
         --  _sbss:  the start of BSS (to be initialized to zero)
         --  _ebss:  the first address after BSS.

         use System.Storage_Elements;

         Sdata : Storage_Element
           with Import, Convention => C, External_Name => "_sdata";
         Edata : Storage_Element
           with Import, Convention => C, External_Name => "_edata";
         Sbss : Storage_Element
           with Import, Convention => C, External_Name => "_sbss";
         Ebss : Storage_Element
           with Import, Convention => C, External_Name => "_ebss";

         Data_Size : constant Storage_Offset := Edata'Address - Sdata'Address;

         --  Index from 1 so as to avoid subtracting 1 from the size
         Data_In_Flash : Storage_Array (1 .. Data_Size)
           with Import, Convention => C, External_Name => "_sidata";

         Data_In_Sram : Storage_Array (1 .. Data_Size)
           with Import, Convention => C, External_Name => "_sdata";

         Bss_Size : constant Storage_Offset := Ebss'Address - Sbss'Address;

         Bss : Storage_Array (1 .. Bss_Size)
           with Import, Convention => C, External_Name => "_sbss";
      begin
         Data_In_Sram := Data_In_Flash;
         Bss := (others => 0);
         Main;
      end Program_Initialization;

   end Startup;

Re: Arduino Due vs Mac

[Jedi Tek'Unum]

A few observations:

On Mac, device names ending in something like usbmodemfd131 are from the Apple driver and the hex ending is related to the physical port number. My experience has been that the Apple drivers, for FTDI at least, are buggy. I always replace it with the driver from FTDI which has always cleared up flaky problems for me. The driver from FTDI names the device with the serial number of the adapter.

I haven't used it with ARM yet, but the ATMEL ICE (BASIC) is fairly inexpensive. With AVR I only use it to burn boot loaders. I never took the time to figure out how to configure tools on OS X to work with it - I just use the ATMEL tool on Windows within VirtualBox.

Have you looked at OpenOCD (http://openocd.net/)?

Re: Arduino Due vs Mac

[Simon Wright]

"Jedi Tek'Unum" <jeditekunum@gmail.com> writes:

> On Mac, device names ending in something like usbmodemfd131 are from
> the Apple driver and the hex ending is related to the physical port
> number. My experience has been that the Apple drivers, for FTDI at
> least, are buggy. I always replace it with the driver from FTDI which
> has always cleared up flaky problems for me. The driver from FTDI
> names the device with the serial number of the adapter.

Giving it a try - I expect I need to reboot, cos the same old
/dev/cu.usbmodem1411 shows up.

> I haven't used it with ARM yet, but the ATMEL ICE (BASIC) is fairly
> inexpensive. With AVR I only use it to burn boot loaders. I never took
> the time to figure out how to configure tools on OS X to work with it
> - I just use the ATMEL tool on Windows within VirtualBox.
>
> Have you looked at OpenOCD (http://openocd.net/)?

Segger have software that provides a gdb server (much like st-util for
STMicro).

You can get the EDU version of the Segger for UKP41 (& I think VAT). You
can get the Segger connector (which needs surgery to fit the Due,
because one of the pins is blanked) for UKP70!!! but there's an Olimex
one for UKP6 or so.

The EDU version is licensed to be used only for non-commercial purposes,
which suits me of course.

Re: Arduino Due vs Mac

[Jedi Tek'Unum]

On Tuesday, July 7, 2015 at 10:31:52 AM UTC-5, Simon Wright wrote:
> "Jedi Tek'Unum" writes:
> 
> > On Mac, device names ending in something like usbmodemfd131 are from
> > the Apple driver and the hex ending is related to the physical port
> > number. My experience has been that the Apple drivers, for FTDI at
> > least, are buggy. I always replace it with the driver from FTDI which
> > has always cleared up flaky problems for me. The driver from FTDI
> > names the device with the serial number of the adapter.
> 
> Giving it a try - I expect I need to reboot, cos the same old
> /dev/cu.usbmodem1411 shows up.

Reboot is easiest (can unload/load).

I think it is also necessary to disable the Apple driver. On Yosemite I go into /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns and rename AppleUSBFTDI.kext directory to something else (I called mine AppleUSBFTDI.kext.disabled).

Re: Arduino Due vs Mac

[Simon Wright]

"Jedi Tek'Unum" <jeditekunum@gmail.com> writes:

> On Tuesday, July 7, 2015 at 10:31:52 AM UTC-5, Simon Wright wrote:
>> "Jedi Tek'Unum" writes:
>> 
>> > On Mac, device names ending in something like usbmodemfd131 are from
>> > the Apple driver and the hex ending is related to the physical port
>> > number. My experience has been that the Apple drivers, for FTDI at
>> > least, are buggy. I always replace it with the driver from FTDI which
>> > has always cleared up flaky problems for me. The driver from FTDI
>> > names the device with the serial number of the adapter.
>> 
>> Giving it a try - I expect I need to reboot, cos the same old
>> /dev/cu.usbmodem1411 shows up.
>
> Reboot is easiest (can unload/load).
>
> I think it is also necessary to disable the Apple driver. On Yosemite
> I go into /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns
> and rename AppleUSBFTDI.kext directory to something else (I called
> mine AppleUSBFTDI.kext.disabled).

You may well be right. Doesn't seem like a very well-thought-out
installation tool that requires me to go into a system directory to
rename/remove a system component instead of just doing it itself.

I'm now getting on OK using bossa with the Apple drivers, so no need for
the FTDI ones. But thanks for the thought.

Re: Arduino Due vs Mac

[Jedi Tek'Unum]

On Tuesday, July 7, 2015 at 4:53:54 PM UTC-5, Simon Wright wrote:
> "Jedi Tek'Unum" writes:
> > On Tuesday, July 7, 2015 at 10:31:52 AM UTC-5, Simon Wright wrote:
> >> "Jedi Tek'Unum" writes:
> >> > On Mac, device names ending in something like usbmodemfd131 are from
> >> > the Apple driver and the hex ending is related to the physical port
> >> > number. My experience has been that the Apple drivers, for FTDI at
> >> > least, are buggy. I always replace it with the driver from FTDI which
> >> > has always cleared up flaky problems for me. The driver from FTDI
> >> > names the device with the serial number of the adapter.
> >> 
> >> Giving it a try - I expect I need to reboot, cos the same old
> >> /dev/cu.usbmodem1411 shows up.
> >
> > Reboot is easiest (can unload/load).
> >
> > I think it is also necessary to disable the Apple driver. On Yosemite
> > I go into /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns
> > and rename AppleUSBFTDI.kext directory to something else (I called
> > mine AppleUSBFTDI.kext.disabled).
> 
> You may well be right. Doesn't seem like a very well-thought-out
> installation tool that requires me to go into a system directory to
> rename/remove a system component instead of just doing it itself.

The Apple driver didn't exist prior to Mavericks.

One would have expected the Apple driver to be fully functional and reliable such that the FTDI driver would never be needed. Alas this is the state of Apple (or more accurately, the industry) these days - incomplete and unreliable.

Renaming the Apple driver creates an ongoing problem with lifecycle as future Apple updates and releases will no doubt put it back in place.

Good that Apple driver is working ok for you. I suspect it won't last :)