Programming without the FTDI connector... (Help)

Other Hardware General Electronics
1

Hello Forum,

So I've had my firmware guy ditch us unfortunately, and leave us without a transition package to help continue the work on our little custom fab PCB project.

I've got 20 units that showed up yesterday from manufacturing, and we didn't populate the FTDI connector because these units are meant for in-field testing.

The MCU is a atmega1284, and our BLE module is MDBT40.

With the shipment from the firmware guy, he sent us over a J-Link debugger and a 6-pin Tag-Connect cable (which don't connect together without the adapter from Segger).

I can of course, manually put in an FTDI connector and jimmy-rig these 20 for firmware upload to the MCU and BLE module but I'd like to do it correctly.

Can someone guide me a bit here? I understand all this, just have 0 experience using it. I've programmed most of our other units via just Arduino installed with the appropriate Moteino MEGA board files.

Much, much, thanks.

2

I don't believe the AVR microcontrollers are supported by the J-Link:

It seems more likely that would be used to program/debug the nRF51 microcontroller on your Bluetooth module rather than the ATmega1284.

3

Hi Pert, thanks for replying...

Maybe they're meant to be used with the AVRISP MkII? It's mentioned in the support documentation we recieved from the original hardware guy...

The AVRISP MkII is a 6 pin, so that actually makes more sense than using the J-Link... Here's a shot of the semi-populated board I had a photo of:

Looks like the MkII is EoL? Again, any and all guidance would be much appreciated.

4

You don't need an AVRISP mkII specifically. Most any AVR ISP programmer can be used. I like the USBasp, which you can buy a 6 pin connector version of for a couple dollars on eBay if you don't mind waiting on the China shipping. If you have a spare Arduino board (or anything that acts as an Arduino board) you can use it as an "Arduino as ISP" ISP programmer by simply uploading the File > Examples > 11.ArduinoISP > ArduinoISP sketch to it and connecting it to your target board with several jumper wires.

Making the connection between the programmer and your target board could be a bit more difficult in this case since it has the tag-connect footprint on the board. You do have the cable though so it shouldn't be too bad. the details of that will depend on what this cable looks like.

You could probably just poke your FTDI connector into the board and hold it at an angle to get the connection long enough for an upload. That might fail occasionally from a poor connection on one of the pins but with a couple tries at most it should go through. That would rely on the ATmega1284 already having a bootloader installed that can receive the uploads. If that bootloader is not on the chip then you will have no option other than to use the ISP programmer, even if that's only to flash the bootloader to the microcontroller. It also seems likely that the FTDI header is only connected to the ATmega1284 (it seems like the silkscreen markings identify the ATmega1284 as "MCU" and the nRF51 as "BLE"). So if you need to upload firmware to the Bluetooth module then the FTDI will not be a complete solution.

5

Indeed, that's why I figure I should just do it the "right" way and get it done without toying around.

I managed to get Amazon to deliver me a MkII tomorrow; so thank goodness for Bezos in this case.

Can you guide me a bit here on what I'll need? I've got the 6 pin cable, the MkII on the way and instructions on how to power the board.

I'm a bit lost as to how I create something that loads to the board that isn't through the regular Arduino "Upload" button. I'm assuming I have to compile the Arduino sketch into a binary of some sort?

Again, lots of understanding on "how" just very little experience in "what".

Thank you again.

6

Choose the programmer you're using from the tools -> programmer menu, hold the connector in place, and do sketch -> upload using programmer (I think that's what the menu it's under is called), instead of the normal upload button. Easy as that.

A bit of design advice - make those 2x3 ISP headers with through holes. The right size of pogo pin will still work, will be easier to hold in place (the points will center it) - but you can just take a piece of 2x3 male pin header, stick it into the connector on your programmer (I use the $3 USBAsps) (these are usually 2x3 female connector), put it in the holes, apply a little force sideways to make sure it makes contact, and upload it - can do it one-handed easily. This is how I bootload the attiny breakout boards I sell in my Tindie store; works great.

7

This is a somewhat a repeat of what DrAzzy said while I was writing this, but there's some additional info so I'm posting it anyway:

If you want help regarding the cable we'd need to have details on your jtag-connect cable. The mkII will come with a 0.1" 2x3 female connector on it so you need to figure out how to adapt that to the jtag-connect footprint.

If this is a fresh microcontroller chip from the factory then the configuration fuses may not be set as required by your hardware. If so, the first step is to set the fuses:

  • (in the Arduino IDE) Tools > Board > select the appropriate board
  • Tools > Programmer > select the appropriate programmer
  • Connect the ISP programmer
  • Tools > Burn Bootloader

That might seem a bit strange to use the "Burn Bootloader" command but that command in the Arduino IDE first sets the fuses according to the hardware definition of the selected board (and any associated custom Tools menu items) before installing the bootloader. So in the Arduino world it's easiest to burn the bootloader even if you only want to set the fuses and are just going to be overwriting the bootloader in the firmware upload step.

So the firmware is an Arduino sketch?

If so you can do this:

  • (in the Arduino IDE) File > Open > open the firmware sketch
  • Tools > Board > select the appropriate board
  • Tools > Programmer > select the appropriate programmer
  • Connect the ISP programmer
  • Sketch > Upload Using Programmer

The Arduino IDE handles the compilation and upload all in the "Upload Using Programmer" step.

Note that if you need to upload firmware to the Bluetooth module as well as the ATmega1284 that will be a separate step and that will likely be done using the J-Link rather than the AVRISP mkII.

8

Thank you both of you...

According to the Tag-Connect website, using the 6-pin no leg is as easy as opening up the ARVISP and replacing the cable as such:

The rest makes a lot of sense, and should be easy for me to handle. The BLE programming is also doable OTA via a phone, so I'll research on how to do that part as well but I'm guessing it can't be all that hard to do it with the ISP as well.

I'll be back with more soon.

9

Here's the link to the OTA system built up by Adafruit:

Here's also the software page to where, yes the J-Link, will be useful in programming the 32-bit MCU:

10

Well, I tried uploading the sketch via the AVRISP now that I have it installed- and everything seems to go smoothly but then, I get gibberish via Putty when I connect to the FTDI adapter...

Previously, I was getting proper serial output of what the loading procedure was at.

Any thoughts? The programmer seemed to upload successfully- am I missing a step after that?

11

Did you do a Tools > Burn Bootloader first before the upload?

12

I tried doing so on that board (burning the bootloader according to the instructions sent via our original hardware guy [basically executing AVRDude via command line]) and it seems to have never come back (burned bootloader, uploaded firmware sketch- same result).

I snagged another board (older), and didn't run into the same issue. There's some error in the firmware however, where a configuration sketch is setting a serial number into EEPROM and then the main firmware sketch is corrupting it somehow- frustratingly, it leads to the payload meant for AWS IoT being scrambled as a hexadecimal mess vs properly formatted JSON output.

I'm having our new hardware/firmware guys jump on it, but that's got my head scratching (I had seen the same issue before, it was fixed by re-running the config sketch and then the primary sketch but that was done via FTDI and these new units obviously don't have it).

On the upside, I know how to burn bootloaders and upload sketches via the AVR ISK MkII... so at least that's a step in the right direction.

Back with more as it develops.

13

Little bit of a random question, how do you get console output if you don't carry a FTDI connector anymore?

Can the 6pin cable output to console through Arduino?

14

No, I don't think there's any way to get output from an AVRISP mkII, or any other 6 pin programmer that I know of. Some of the 10 pin USBasp programmers do have the UART pins on the connector and there is a version of that firmware that allows you to use it as both an ISP programmer and USB-TTL serial adapter but of course you would need to have a way to connect that 10 pin connector to your board.

bolteon:
I get gibberish via Putty when I connect to the FTDI adapter...

Are you still having that problem?

bolteon:
There's some error in the firmware however, where a configuration sketch is setting a serial number into EEPROM and then the main firmware sketch is corrupting it somehow

Depending on the setting of the EESAVE fuse bit, the EEPROM may be erased every time you do a Tools > Burn Bootloader or Sketch > Upload Using Programmer. That fuse will be set according to the value of bootloader.high_fuses in the boards.txt entry for the board you have selected from the Tools > Board menu at the time you burn the bootloader. I just checked the MoteinoMEGA hardware definition from the LowPowerLab Moteino hardware package 1.3.0 and indeed it is not configured to preserve EEPROM (which is the standard setting in the Arduino AVR Boards also). If you want to change that behavior then you can edit the boards.txt and change line 28 of the Moteino boards.txt from:

MoteinoMEGA.bootloader.high_fuses=0xDE

to:

MoteinoMEGA.bootloader.high_fuses=0xD6

Remember that you need to close all Arduino IDE windows and then start the IDE again before any changes to boards.txt take effect. If you need help finding that boards.txt file let me know.

15

pert:
Depending on the setting of the EESAVE fuse bit, the EEPROM may be erased every time you do a Tools > Burn Bootloader or Sketch > Upload Using Programmer.

I swear to jebus if that's the issue; I'm going to buy you dinner sir.

Makes a lot of sense and explains why when uploading via FTDI- I had the issue go away.

Gibberish board is still gibberish, haven't played with it much but maybe I can bring it back from the dead.

My bootloading instructions were as such:

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude" -C "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -v -patmega1284p -cstk500v2 -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xDE:m

...followed by:

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude" -C "C:\Program Files(x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -v -patmega1284p -cstk500v2 -Pusb -Uflash:w:"C:\DualOptiboot_V5.0_atmega1284p_BlinkD15.hex":i -Ulock:w:0x0F:m

No mention of the high fuses, and secondly- later tonight... I'll test reloading the config script twice on a board, if it is erasing the EEPROM after each upload via ISP; it'll bork the written code in EEPROM as well.

Pretty sure this is the "boards.txt we're discussing?

C:\Program Files (x86)\Arduino\hardware\arduino\avr

A shame about the 6 pin not being able to output UART- down the line, I'll have our new firmware guy add code to the BLE module to communicate serial output wirelessly.

Back in a bit, and a heartfelt thank you for the assistance. I've delayed our launch to crowdfunding by 4 weeks in case we couldn't get this figured out in short order, lots left to do and lots of "polish potential" so if I can get this settled, I'll be able to focus on other things over the next 6 weeks.

16

...actually, I'm guessing it's this boards.txt:

C:\Users\User\AppData\Local\Arduino15\packages\Moteino\hardware\avr\1.3.0
17

Here's the boards.txt modifications that were sent over by the first hardware guy... some settings are different than what's in the standard boards.txt when installing the 1.3.0 MoteinoMEGA board setup:

##############################################################

MoteinoMEGA.name=MoteinoMEGA
MoteinoMEGA.upload.tool=arduino:avrdude
MoteinoMEGA.upload.maximum_size=130048
MoteinoMEGA.upload.maximum_data_size=16384 MoteinoMEGA.upload.speed=115200
MoteinoMEGA.upload.protocol=arduino 
# This line added 
MoteinoMEGA.bootloader.tool=arduino:avrdude
MoteinoMEGA.bootloader.low_fuses=0xDE
MoteinoMEGA.bootloader.high_fuses=0xDE
MoteinoMEGA.bootloader.extended_fuses=0xFD
#MoteinoMEGA.bootloader.extended_fuses=0x05  Didn't need this! 
MoteinoMEGA.bootloader.unlock_bits=0x3F
#MoteinoMEGA.bootloader.lock_bits=0xCF   Programmer expects 0x0F
MoteinoMEGA.bootloader.lock_bits=0x0F
MoteinoMEGA.bootloader.file=MoteinoMEGA/DualOptiboot_V5.0_atmega1284p_BlinkD15.hex
MoteinoMEGA.build.mcu=atmega1284p
#MoteinoMEGA.build.f_cpu=16000000L
MoteinoMEGA.build.f_cpu=10000000L
MoteinoMEGA.build.core=arduino:arduino
MoteinoMEGA.build.variant=MoteinoMEGA
MoteinoMEGA.build.board=AVR_MOTEINOMEGA

##############################################################

I'm a little lost as to whether those settings above are considering axiom since they're a couple years old in instruction...

18

Does your 1284p use a 10MHz crystal? That’s one of the changes made to the file. Piecing together the correct fuse settings is a bit more work.

Additionally, the name of the bootloader is a bit odd, wouldn’t be my choice for a custom 10MHz variant.

19

avr_fred:
Does your 1284p use a 10MHz crystal? That’s one of the changes made to the file. Piecing together the correct fuse settings is a bit more work.

Additionally, the name of the bootloader is a bit odd, wouldn’t be my choice for a custom 10MHz variant.

Indeed, up until our Rev4 changes- we've been using a 10MHz oscillator. We've switched to 16 in the most recent setup.

Perhaps that would explain the gibberish board that wont function properly anymore... More research tonight!

20

A 16MHz crystal means you need a 16MHz bootloader and the correct boards.txt file - the one you posted is obviously for the older boards. The high fuse bit for preserving EEPROM contents is 0x08 so it’s on with a value of 0xDE.