Forum > Embedded - ARM
Arduino DUE
Mathias:
I have adopted your code 1: 1, this also does not work.
I also uploaded your hex once, there is the following output:
--- Code: ---$ /home/tux/.arduino15/packages/arduino/tools/bossac/1.6.1-arduino/bossac --port=ttyACM0 --info -e -w -v -b test.hex -R
Atmel SMART device 0x285e0a60 found
Device : ATSAM3X8
Chip ID : 285e0a60
Version : v1.1 Dec 15 2010 19:25:04
Address : 524288
Pages : 2048
Page Size : 256 bytes
Total Size : 512KB
Planes : 2
Lock Regions : 32
Locked : none
Security : false
Boot Flash : false
Erase flash
done in 0.033 seconds
Write 2893 bytes to flash (12 pages)
[==============================] 100% (12/12 pages)
done in 0.573 seconds
Verify 2893 bytes of flash
[==============================] 100% (12/12 pages)
Verify successful
done in 0.545 seconds
Set boot flash true
CPU reset.
--- End code ---
Nothing happens there, except that I have to reset the Com-Port, who I upload from the Arduino IDE.
The ST-Link line is still a mess because I modified an example from an ST32.
MiR:
I played arround a while with bossac and then gave up, the problem seems to be that I am too stupid to use that tool and sam-ba is even worse.
With my trusty JLink things are flashed in a second and all works as expected, with bossac I am unable to flash the device.
Part of the problem may be that bossac (I think) only supports bin files, when I write a hey file the flash memory looks like it is filled with the ascii chars of the hex file.
There are also several different bossac versions, a special version that comes with Arduino and latest/greatest which is V1.9.1
commandline I use was:
bossac -i --port=cu.usbserial-1440 -U false -e -w -v -b Project1.bin -R
but I tried a lot of other versions.
Sometimes I thought I had it running, then I redid and it stopped working.
Perhaps you have more luck, attaching my working bin file
Mathias:
I've tried your Project.bin in your attachment. With multiple uploads, it works in between. bassac I used the 1.9.1.
Can't you upload the sources of your project with?
I never got it done with my project.
From the looks of it, a DUE is a pretty annoying part.
With the following code, I can reset the COM port:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---var SerialHandle: TSerialHandle;begin SerialHandle := SerOpen('/dev/ttyACM0'); SerSetParams(SerialHandle, 1200, 8, NoneParity, 1, []); SerSetDTR(SerialHandle, True); SerSetDTR(SerialHandle, False); Sleep(500); SerClose(SerialHandle); Sleep(500);
This command also looks a bit strange: --port=cu.usbserial-1440
--- Quote ---Part of the problem may be that bossac (I think) only supports bin files, when I write a hey file the flash memory looks like it is filled with the ascii chars of the hex file.
--- End quote ---
Funnily enough, he even uploads a Project.pas %)
MiR:
Source attached....
I used bossash to better see what is going on, there I can flash, verify and dump the code:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---bossa> connect /dev/cu.usbmodem14401Connected to device on /dev/cu.usbmodem14401bossa> eraseErase flashFlash is erasedbossa> dump 0x80000 0x100 0 1 2 3 4 5 6 7 8 9 a b c d e f00080000 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������00080010 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������00080020 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������00080030 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������00080040 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������00080050 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������00080060 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������00080070 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������00080080 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������00080090 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������000800a0 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������000800b0 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������000800c0 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������000800d0 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������000800e0 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������000800f0 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ����������������bossa> write Project1.binWrite 521 bytes to flash (3 pages)[==============================] 100% (3/3 pages)Write successfulbossa> dump 0x80000 0x100 0 1 2 3 4 5 6 7 8 9 a b c d e f00080000 | 00 00 01 20 89 01 08 00 85 01 08 00 00 00 00 00 | ... ............00080010 | 85 01 08 00 85 01 08 00 85 01 08 00 00 00 00 00 | ................00080020 | 00 00 00 00 00 00 00 00 00 00 00 00 85 01 08 00 | ................00080030 | 85 01 08 00 00 00 00 00 85 01 08 00 85 01 08 00 | ................
I found a clone with CH340 chip instead of the original, there I sometimes see that after flashing the memory is dumped as all zeros, looks like the chip is not properly connected at that point but there is no error message at all.
I can flash the code via bossash, then connect with my Jlink and the code works, so I guess flashing is ok and there is some magic ingredience missing in the code. I see in the debugger that WDT is disabled, perhaps it is worth disabling it in code, too, but I doubt it.
I fear that you will have to look through ther initialization in the C Header files to find that magic missing part.
MiR:
--- Quote from: Mathias on August 07, 2020, 09:45:11 am ---From the looks of it, a DUE is a pretty annoying part.
--- End quote ---
It is by far not my favorite path (I do not like the way that atmel Reference Manuals are written) but the problems we see right now have nothing to do with the chip itself.
By the way,
/dev/cu.usbmodem14401
is the serial device of the Arduino Due on my mac.
Navigation
[0] Message Index
[#] Next page
[*] Previous page