Burning at90can128 bootloader on custom pcb, device signature = 0xffffff

[jasontz]

Hello I am trying to burn a bootloader onto an AT90CAN128, previously using the can485 board from sparkfun before placing the chip onto a custom pcb.

While both the original and a previous version of the board was able to be burnt to, the current version only returns variations of 0x000000 and ff s which I can tell from searching means somethings likely wrong with shorting but I can't tell where. If any advice on what or where to check would be greatly appreciated. Quick note that for the at90can128 RX is connected to MOSI and TX is connected to MISO

Current observations: VCC led turns on, Green LED connected to SCK flashes when reset button is pressed, green led does not turn on when power is directly connected to the board rather than board connected to uno as isp.

The same uno is being used as Arduino as ISP for all three situations.
Current schematic, IC2 is a temp sensor

FTDI header being used to connect RX to MOSI and TX to MISO

same section on previous board

verbose setting on
avrdude: Version 6.3-20190619
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

     System wide configuration file is "C:\Users\jason\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf"

     Using Port                    : COM6
     Using Programmer              : stk500v1
     Overriding Baud Rate          : 19200
     AVR Part                      : AT90CAN128
     Chip Erase delay              : 9000 us
     PAGEL                         : PD7
     BS2                           : PA0
     RESET disposition             : dedicated
     RETRY pulse                   : SCK
     serial program mode           : yes
     parallel program mode         : yes
     Timeout                       : 200
     StabDelay                     : 100
     CmdexeDelay                   : 25
     SyncLoops                     : 32
     ByteDelay                     : 0
     PollIndex                     : 3
     PollValue                     : 0x53
     Memory Detail                 :

                              Block Poll               Page                       Polled
       Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
       ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
       eeprom        65    20     8    0 no       4096    8      0  9000  9000 0xff 0xff
       flash         65     6   256    0 yes    131072  256    512  4500  4500 0xff 0xff
       lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
       hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
       efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
       lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
       calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
       signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

     Programmer Type : STK500
     Description     : Atmel STK500 Version 1.x firmware
     Hardware Version: 2
     Firmware Version: 1.18
     Topcard         : Unknown
     Vtarget         : 0.0 V
     Varef           : 0.0 V
     Oscillator      : Off
     SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0xffffff (probably .avr8x_mega) (retrying)

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0xffffff (probably .avr8x_mega) (retrying)

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0xffffff (probably .avr8x_mega)
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.

[Budvar10]

I have no experience with this MCU type. Based on brief info, I suppose it could be similar to ATmega. Receiving only 0xFF bytes points to shortage on the ISP data wire, receiving only 0x00 points to not connected data wire or not running MCU at all. If there is a combination of these, I would say it is HW problem with floating wire or maybe somewhere else.

@jasontz

...when power is directly connected to the board rather than board connected to uno as isp.

This is suspicious.

[rsmls]

@jasontz

Current schematic

Could you post a full one? I'm not sure what's missing at the bottom, but since it's cropped off there, I get the impression we're not getting to see everything.

Can you show the schematic of the previous board that did work?

How does SCK connect to your ISP in the present board?

Can you show some good photos of the boards as assembled?

[hansibull]

As pointed out by others, the schematic is incomplete. But one thing to pay attention to is that the ISP pins on the AT90CAN128 uses the PDI/PDO pins, not MISO/MOSI for ISP programming.

See recommended minimal setup schematic here:

GitHub - MCUdude/MegaCore: Arduino hardware package for ATmega64, ATmega128,...

[jasontz]

I have some more images
For the Current version

IC2 is a temperature sensor

much of this is just taken from https://cdn.sparkfun.com/assets/c/4/c/e/5/SparkFun_AST-CAN485_1.zip alongside another one of their boards.

And here is the first version of the pcb, The main change would be that addition of the temperature sensor and the changing of a power switch to a fuse, but the VIN is a separate power input unrelated to the FTDI header + SCK pin being used for the bootloader burning.

@hansibull

As pointed out by others, the schematic is incomplete. But one thing to pay attention to is that the ISP pins on the AT90CAN128 uses the PDI/PDO pins, not MISO/MOSI for ISP programming.

It is unfortunately not this as I noted in the original that the flashing worked fine on both the original sparkfun board and the 1st version of this pcb which uses the same connections as this one. For extra proof here's a zoom in on the unit that it is connected to pin 2 and 3, which are PDi and PDo respectively.

I can upload the board files if need be and here are some photos of the pcb itself
Current version

IC2 is missing because I desoldered it vainly hoping that would change something (it did not). In fact it might have bricked the board entirely because now the SCK line is acting extremely strangely, with the LED being very dim and neither board's reset button causing flickering. I will solder another one today.

Original version which does burn the bootloader properly and can have sketches uploaded to.

I don't believe it has anything to do with the soldering either as the original version has markedly worse soldering and I have tried on two different boards for the current version.

I am also going to admit that it has been a minute since I've checked for shorts so I don't exactly remember what I'm looking for but when I check the voltage across the VCC and the RXI, TXO, and SCK pins then there is a 4V difference and across VCC and GND there is a 5V difference so I assume that is not an issue either? Any advice on how to check this properly would be greatly appreciated.

Hopefully this is enough information to point me in a direction. Also if I wanted to upload the board files I assume I should put them on github and link there?

[rsmls]

Thanks for adding those; off the bat, I can't really see anything different between the working and the non-working version.

Speaking of soldering, I've had cases (quite a few actually) where QFN components didn't connect well with their pads on the PCB. Inspect the contacts with a loupe/microscope. I've only had this happen with DIY boards and home-soldered stuff; yours seems to look better so I wouldn't expect this to be a problem...then again, I would have expected this to work, and yet, it doesn't!

@jasontz

VCC and the RXI, TXO, and SCK pins then there is a 4V difference

Sounds odd; where does the remaining 1V go?

[jasontz]

Soldered a new one, in testing for continuity I did not find any shorts between VCC and SCK/TXO/RXO, but between VCC and GRN there was occasional continuity which I find confusing given there is a capacitor and resistor connecting VCC to the Reset line. Is it possible that its here that there's the issue? Or am I just misunderstanding something about how this works

Nevermind I had it on when I was testing it, but when I tested resistance and continuity between them all with it off there wasn't any between any which makes the 0xFF even more confusing to me

quick board photo, the DTR RESET connection is a 0.1uF capacitor, and VCC RESET connection is a 10k resistor

[jasontz]

A suggestion was that I may have messed up with the clock somewhere. Looking at the oscillator is it possible putting vias too close to it may have messed it up? I dont believe it was the trace length as the original version is similarly close.

Original

The opposite sided component is a mosfet here.

Current

the opposite sided component here is a spectral light sensor. I would assume that through a 4 layer board that it wouldn't interfere with it but at this point I'm just guessing

sparkfun can485

with how dense this board is compared to mine I would assume this is not looking in the right place for issues but who knows.

[Budvar10]

Isn't oscillator set to the internal RC by default until it is set by programming? It can't affect anything if the pins are in high impedance state.

However, you should check the board for any production deviation from the design if there are doubts.

[rsmls]

@jasontz

Looking at the oscillator is it possible putting vias too close to it may have messed it up?

Nah.

[jasontz]

@rsmls

Nah.

drat