Awesome, glad we can communicate and work through all these issues!
About the download - the speed is probably limited by what our servers can handle. I imagine that a decent number of people are trying to access those files right when I release new updates. I’ll talk to our IT guys to see if we can think of a way to deliver it better.
Good to know about the LEDs you have on TR/RX - Based on your description I don’t suspect that as the problem.
This raises a flag in my mind:
Attempt to upload code, with BOOT tied to 3.3V
" error receiving packet
{'len': 0, 'cmd': 0, 'data': 0, 'crc': 1, 'timeout': 1}
unknown error
Upload failed"
because the error message is one from the SparkFun Variable Loader (SVL), but holding the BOOT pin high tells the Artemis module to go into the “true” boot mode using the Ambiq Secure Bootloader (ASB). They are incompatible modes. So let me explain a little more:
ASB: a bootloader baked into the APollo3 chip with some configurability. It is activated by the “BOOT” strapping pin being high when a reset occurs. (It also can be activated when “BOOT” is low at startup, and the “BOOT” pin is configurable depending on settings programmed with a debugger. All the Artemis modules use pad 47 and the HIGH polarity for bootload mode, however the original Edge baords used pad 14 and the LOW polarity. ) After that the ‘ambiq_bin2board.py’ python script is used to perform bootloading steps.
SVL: an additional bootloader that an be flashed into the chip using the ASB – designed for convenience. It resides at the location in memory that the ASB expects an application to live so that it runs when the ASB exits. It has a short window of time to receive a ‘U’ character (to detect baud rate) and then confirm bootloading intent via UART in order to begin, otherwise it jumps execution to the location where it expects an application to live.
So, if you hold the boot pin high and try to use the SVL nothing will work. Also should note that when you use the ASB it overwrites the SVL with your application – to use the SVL after using the ASB you need to re-upload the SVL using the ASB. That is done with the steps you linked (‘All About the Artemis Bootloader’). I am confused how you got the SVL error messages when following those steps. Can you provide the entire output by turning on verbose output for compilation and upload in the Arduino settings?
There is only one board definition that allows you to select the ASB baud rate – that is the Edge. This is because the ASB baud rate is not configurable by a user without a programmer/debugger. However the Edge was distributed in two different flavors, one with the ASB configured for 921600 baud and one configured for 115200 baud. All other boards (including all boards based on the Artemis module) are configured to use 115200 baud for the ASB.
As a note: the ‘burn bootloader’ option should use the configured ASB baud rate for upload (that is it will be 115200 on every board except an Edge board with 921600 selected as the baud rate for ASB)
I don’t know of any batch markings on the Artemis modules… I’ll bring this up with the engineer in charge of the HW. Seems like it could be a good thing to check. However AFAIK there have been no software or hardware changes to the Artemis modules. Since these are the engineering samples Mouser and other distributors would have purchased them directly from us.
Another tidbit: FCC certified Artemis modules for production are coming soon. The only significant difference will be that the module is canned for RF.
So in summary please make sure that you’re using the ASB tool (called ‘ambiq_bin2board’) for the ‘burn bootloader’ step, and provide as much of the console output as you can so that we can get a more clear idea.