Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Scripts to support Atmel SAM3 chips
#1
Here are some scripts for the ATSAM3xx line of Atmel/Microchip chips.  Boy were these easier than the NXP LPC scripts.  I don't know why NXP made their chip flashing procedure so difficult.

I also made a small change to the Cortex-M0 section in the atmel-auto.script so that it wouldn't incorrectly detect non-Atmel chips as Atmel when using the auto.script.


Attached Files
.zip   sam3.zip (Size: 5.17 KB / Downloads: 52)
Reply
#2
(20-04-2023, 04:18 PM)jdubois Wrote: Here are some scripts for the ATSAM3xx line of Atmel/Microchip chips.  Boy were these easier than the NXP LPC scripts.  I don't know why NXP made their chip flashing procedure so difficult.

I also made a small change to the Cortex-M0 section in the atmel-auto.script so that it wouldn't incorrectly detect non-Atmel chips as Atmel when using the auto.script.

Thank you very much indeed
Reply
#3
You're welcome. It kind of happened by accident, as I was looking through my bins for a dev board for the SAMD21 chip and ran across one for an older SAM3 and wondering if it still worked... and as it turned out to be pretty simple to code the scripts, here they are.
Reply
#4
General happy with the scripting approach? Suggestions? Improvements?
Documentation is already noted.

Are you making use of the EBlink shell menu's?
Reply
#5
Yes, once I figured out the peculiarities of the squirrel scripting language, the scripting works really well. I'm actually impressed with how much you can do, and I suspect there's even more power in the APIs that I haven't discovered. For the command line interface to EBlink, I noted that there's no 'erase sector' command. Not sure exactly when you'd need that, but just noticed it. I actually noticed it when I noted that the SAM3 chips don't have the ability to erase a single sector.

Haven't done anything with the shell menus. Didn't even know they were a thing.

BTW, I noticed another weirdness with .SVD files in EmBitz. At least I think I did. I want to explore it more and then I'll post it in the appropriate place.
Reply
#6
There are bugs in the svd viewer with the notation that Atmel is using.
These are solved in the next 2.60. Addresses and offsets are wrong for inherited peripherals.

I will see if I can publish 2.60 this weekend.
Reply
#7
Ok, that could well be this issue. It Seemed to be getting the address wrong for registers in a cluster element.
Reply
#8
Yip, that is the case (amongst others)
Reply
#9
When I was testing the final release package of EBlink 4.8 with your script commits, the cortex-m0 Atmel were not discovered anymore so I reverted to the original discovery code for cortex-m0.

It's always hard to make this trustable working but if it works it is so easy to just right click your elf or hex files in explorer and just flash it without any concerns about cli settings etc. Especially if you are working with multiple MCU vendors in one project like I'm doing currently. Due to MCU shortages this is more often the case nowadays.
Reply
#10
Hmm, yeah, ok. Which chip were you using that wasn't discovered? Better to pull it out of the release and we can keep working on it.
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)