Maybe a problem with CKOUT (ATmega32U4)

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello I'm new here and I hope someone can help me. :)

First of all I have to say that I'm also relatively new to electronics (e.g. today I used an oscilloscope for the first time ;) ) - so please don't bash me, if I'm asking stupid questions. :P

 

I have the following problem:

 

I'm trying to use an ATmega32U4 in combination with a MCP2515. 
I have burned the Arduino Leonardo bootloader onto it and set the fuses to LFuse: 0xBF, HFuse: 0xD0 EFuse: 0xCB. So the clock should be outputted at pin PC7. I've connected PC7 to pin 'OSC1' (pin 8) at the MCP2515.
The SPI bus is also connected properly.
I have changed the SPI lines at the library to:

#define P_MOSI B,2

#define P_MISO B,3

#define P_SCK B,1

//#define MCP2515_CS D,3 // Rev A

#define MCP2515_CS B,0 // Rev B

#define MCP2515_INT E,6

#define LED2_HIGH B,5

#define LED2_LOW B,5

 

If I try to initialize the CAN Bus, I get an error "CAN Init error". 

 

So I guessed that the Clock Output is faulty.

I have connected an oscilloscope to the OSC1 pin and got the following graph.

 

Is it normal, that the clock output looks like this?

To make comparisons I've also checked the 16MHz Crystal. This wave looks better for me.

So am I right, that there is a problem with the CKOUT and if so, what can I do? ;)

I thank you very much for your help and hope you can understand me because English isn't my native language.

Greetings

Daniel

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Please post a schematic if your circuit and a picture of your setup would be nice too. 

 

Jim

 

Mission: Improving the readiness of hams world wide : flinthillsradioinc.com

Interests: Ham Radio, Solar power, futures & currency trading - whats yours?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't help wondering about your actual scope probes and their grounding.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I can't help wondering about your actual scope probes and their grounding.

I'm not a sparky, but inded probe and grounding.  And also what is being driven.  The picture looks like ringing.  So signal is bouncing off the end of a fly-wire of say a few centimeters?

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I had a quick and superficial  look at 2515 datasheet : OSC1 -pin 8 - has a  rather high noise immunity see table 13.1, p70.

What might make signal strange can be : weird PCB/ wires, with stray capacitances /inductance; way the oscilloscope is connected;  oscilloscope used on the limits of its frequency range...

 

Thus, as kiObk asked, a picture (a "smart" "phone" can be very easy to use : import the picture(s) into your PC, then grab and drop) can be used to detect non standard/faulty wiring.

 

A schematics (can be drawn with a pen and sheet of paper; if you do not have an existing schematics, you can deduce it from your physical layout -a way of detecting horrors, if any-) can be very useful (one needs the schematics as they are, not as they should be).

 

I might add to kiObk  question whether you have already written some software (if someting is very wrong, people protest...)

 

There is another thing which bothers me : from  chpter 8.2, page 53 , there is a clockout pin (3) and should be 2 Mhz at init. Did your oscilloscope look at it?

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's a Siglent SDS1104X-E with its original probes (BW 100MHz).

All four probes had been calibrated before use and all show the same graph. 
Why should there be only a measurement error at this specific trace? The graph of the crystal is a nice sine wave. Shouldn't it be also faulty if there would be a problem with the probes?

 

The setup is the following:

The components are situated on a printed PCB. The PCB has a connector and the wires of the connector are connected to a power supply (12V) via alligator clips. The alligator clip of the probe is connected to the power supply's alligator clip (GND).

The tip of the probe is pressed onto the corresponding pin of the IC.

 

I will hand in the schematic later.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know nothing about electronics but you may want to make the Gnd connection closer to the actual Gnd pin(s) of the micro.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If scope is not faulty, perhaps there are issues with PCB: you should show the hardware as it is.

 

If noise /harmonics immunity is enough, at reset (at least, if I understood application note), pin 3 should show a 2 Mhz (16/8) signal...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can't use just any GND connection when looking at signals in the MHz range, and expect to see good signals. 

Again, a picture would help us help you!  What is the overall goal of your project (a little background info helps too).

Welcome to the Freaks forum!

 

Jim

 

 

Mission: Improving the readiness of hams world wide : flinthillsradioinc.com

Interests: Ham Radio, Solar power, futures & currency trading - whats yours?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dbrion0606 wrote:

If scope is not faulty, perhaps there are issues with PCB: you should show the hardware as it is.

 

If noise /harmonics immunity is enough, at reset (at least, if I understood application note), pin 3 should show a 2 Mhz (16/8) signal...

 

This is the PCB. https://1drv.ms/u/s!Aji7fRe9Qkh2...
I had to cut two traces (CS and MISO) and swap them, because I had mixed them up. Of course I noticed the mistake only when the PCB was produced - I'm a genius I know. :D :P 
The second cable is at the top side of the PCB. (There aren't any components).

 

I've also checked the pin 3. This is the graph.

 

 

 

Edit: The 'test setup' looks like this. https://1drv.ms/u/s!Aji7fRe9Qkh2...

The left clip is +12V and the right one GND.

 

ki0bk wrote:

You can't use just any GND connection when looking at signals in the MHz range, and expect to see good signals. 

 

Which GND connection do I have to use? I thought the GND clip of the power supply would be ok because the complete PCB has only one ground plane.

 

It's universally usable. I used CAN Shields and the ATmega328p before (for house automation, cars and so on). I wanted to exchange the 328p to get everything smaller (with built-in USB) - and here we are. :D

 

Thanks for the welcome. :)

Last Edited: Tue. Jun 12, 2018 - 06:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The side I saw seems very beautiful. Maybe my eyes are very old.

 

Maybe other side is uglier...

I was terrified by your scope (you should change the timebase), until I noticed , at the NE corner f=2Mhz. Seems it agrees with application note.

If 2515's CLOCKOUT is derved from OSC1, seems -part- of your circuit is OK, and is fed by a clean -for it- enough signal (consistent with noise immunity) . Then error is ... elsewhere (

other side of the PCB,

schematics,

fuses (already here),

software?).

 

Nota: for making other, more competent people,  life easier to detect any flaw, my mouse  I just ...copied and paste... the side of PCB I saw.

 

from your test setup, scope probe  has long, loopy on the ground side,  wire ....

 

Last Edited: Tue. Jun 12, 2018 - 06:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scrape a bit of the solder mask off and solder a short 1cm wire 'tail' (ie resistor leg offcut) onto the ground plane. Use that for your scope probe ground connection.

 

See #2 in my signature.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

Last Edited: Tue. Jun 12, 2018 - 07:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

Scrape a bit of the solder mask off and solder a short 1cm wire 'tail' (ie resistor leg offcut) onto the ground plane. Use that for your scope probe ground connection.

 

See #2 in my signature.

 

I think I have good news. I did it as you described. (I could use an SMD pad instead of scraping of soldermask)

The graphs aren't perfect but it looks more like a square wave - so I think @dbrion0606 is right and the CKOUT isn't the problem.

 

 

 

I will upload schematics and so on tomorrow. The Siglent also has a decoder function, so maybe I can decode the SPI bus - even if I don't know until now how to securely connect four probes at the same time. :D

 

For now I'd like to thank everyone for the help. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Little Helper wrote:
it looks more like a square wave
You still have not said what you have attached.  If a fly wi9re -- of course you are going to get ringing; echo from the far end.

 

What do you get when you drive a high-impedance load? It probably looks pretty clean.  Now, you have calibrated probes, you said, but you could try playing with the screw--I'll bet the result will change some.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The second trace in #13 is about what I would expect with a low(er) cost scope and a low performance "probe" (though the sample rate is plenty fast). Bet you those spikes are not really (overshoot) spikes but related to the propagation time of the probe. A typical probe of this kind consists of a piece of coax with a BNC connector on one end and two alligator clips on the other. You can also get this behavior with a 10X probe that uses ordinary coax. A 10X probe with a long ground lead from the back end of the probe makes this even worse. Good HiZ probes use coax with a special resistive center conductor to spoil this behavior. 

 

As a general statement, good analog scope measurements with signals faster than, say,10-15ns (rise/fall times), is plenty challenging, even with excellent equipment. I can remember when 100MHz bandwidth (3.3ns rise/fall time) was a huge technical hurdle. And, probes that would handle those speeds were virtually non-existent. 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did it as @Brian Fairchild said: 'solder a short 1cm wire 'tail' (ie resistor leg offcut)'. There I connected the GND clip of the probe.

The probes are Siglent PP510. Today I removed the GND clip and replaced it with a 'Ground spring' which was included in the package. The description says: 'Provides shorter grounding path for better signal integrity'. So I pushed this spring onto the GND-pin of the MCP2515. The results look better for me. So I would say, the CKOUT isn't the problem. I think the SPI is the problem.

 

 

 

I uploaded this code to the ATmega32U4:

 

#include <Canbus.h>
#include <defaults.h>
#include <global.h>
#include <mcp2515.h>
#include <mcp2515_defs.h>

String test = "init";

void setup()
{
  Serial.begin(115200);
  //Initialise MCP2515 CAN controller at the specified speed
  if(Canbus.init(CANSPEED_125)){
    Serial.println("CAN Init ok");
    test = "ok";
    }
  else{
    Serial.println("CAN Init Error");
    test = "Error";
    }
  delay(1000);
}

void loop()
{
  Serial.println(test);
}

The Serial Monitor only displays 'Error'. If I use the same code on an ATMega328p, it will initialize correctly.

Here are the schematics for the MCP2515 and the 32U4. I hope it's ok with the external links but onedrive couldn't be used as external media link. :/

 

https://1drv.ms/u/s!Aji7fRe9Qkh2...

 

https://1drv.ms/u/s!Aji7fRe9Qkh2...

Last Edited: Wed. Jun 13, 2018 - 11:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Excuse me, but I do net see how !RESET is connected, and therefore cannot figure out how reset lasts > 2us after power up (AN , chap 9 p55)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Reset line of the MCP2515 is connected to the Reset line of the ATmega32U4. It's connected to the SMD Pad 'R1'.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Have you got equipment to test SPI (showing bytes in/out coming)? Do you know how to manage them (I do not)

 

IF SPI is OK (or cannot be tested : sending orders and clock to SPI in a loop can be checked with oscilloscope -"checks" MOSI, CK and SS, but a continuity check is enough and can "check" MISO).

In a loop is dubious : your scope can be triggered with !CS?

 

Where does mcp2515.h come from?

I had a look at https://github.com/franksmicro/A...

maybe you might cut and paste (if it is the right source)


boolean MCP2515::initCAN(int baudConst)
{
  byte mode;

  SPI.begin();

  digitalWrite(SLAVESELECT,LOW);
  SPI.transfer(RESET); //Reset cmd
  digitalWrite(SLAVESELECT,HIGH);
  //Read mode and make sure it is config
  delay(100);
  mode = readReg(CANSTAT) >> 5;
  if(mode != 0b100) { //*****modified*** added opening brace
serial.println("readReg failed"); // extra debugging line
    return false;
	                                } // added closing curly brace, too
  return(setCANBaud(baudConst));

}

boolean MCP2515::setCANBaud(int baudConst)
{
  byte brp;

  //BRP<5:0> = 00h, so divisor (0+1)*2 for 125ns per quantum at 16MHz for 500K
  //SJW<1:0> = 00h, Sync jump width = 1
  switch(baudConst)
  {
    case CAN_BAUD_500K: brp = 0; break;
    case CAN_BAUD_250K: brp = 1; break;
    case CAN_BAUD_125K: brp = 3; break;
    case CAN_BAUD_100K: brp = 4; break;
    default: return false;
  }
  digitalWrite(SLAVESELECT,LOW);
  SPI.transfer(WRITE);
  SPI.transfer(CNF1);
  SPI.transfer(brp & 0b00111111);
  digitalWrite(SLAVESELECT,HIGH);  

  //PRSEG<2:0> = 0x01, 2 time quantum for prop
  //PHSEG<2:0> = 0x06, 7 time constants to PS1 sample
  //SAM = 0, just 1 sampling
  //BTLMODE = 1, PS2 determined by CNF3
  digitalWrite(SLAVESELECT,LOW);
  SPI.transfer(WRITE);
  SPI.transfer(CNF2);
  SPI.transfer(0b10110001);
  digitalWrite(SLAVESELECT,HIGH); 

  //PHSEG2<2:0> = 5 for 6 time constants after sample
  digitalWrite(SLAVESELECT,LOW);
  SPI.transfer(WRITE);
  SPI.transfer(CNF3);
  SPI.transfer(0x05);
  digitalWrite(SLAVESELECT,HIGH); 

  //SyncSeg + PropSeg + PS1 + PS2 = 1 + 2 + 7 + 6 = 16

  return true;
}

add Serial.prints  (seems it works) at different steps of init, and rename two functions   "initCAN" and "setCanBaud"  (you should modify the.h file accordingly) in order to find out where it is broken.

Edited: what I hint  a brute force debugging "method" , and can lead to having two software versions, and various options of Murphys law. I could not figure out a better/less bad  one.

 

Last Edited: Wed. Jun 13, 2018 - 12:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's the sparkfun CAN Library.
https://github.com/sparkfun/Spar...

 

This is the content of the mcp2515.h

 

#ifndef	MCP2515_H
#define	MCP2515_H

// ----------------------------------------------------------------------------
/* Copyright (c) 2007 Fabian Greif
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS "AS IS" AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */
// ----------------------------------------------------------------------------

#include <inttypes.h>

#include "mcp2515_defs.h"
#include "global.h"
#ifdef __cplusplus

extern "C"
{
	

#endif
// ----------------------------------------------------------------------------
typedef struct
{
	uint16_t id;
	struct {
		int8_t rtr : 1;
		uint8_t length : 4;
	} header;
	uint8_t data[8];
} tCAN;

// ----------------------------------------------------------------------------
uint8_t spi_putc( uint8_t data );

// ----------------------------------------------------------------------------
void mcp2515_write_register( uint8_t adress, uint8_t data );

// ----------------------------------------------------------------------------
uint8_t mcp2515_read_register(uint8_t adress);

// ----------------------------------------------------------------------------
void mcp2515_bit_modify(uint8_t adress, uint8_t mask, uint8_t data);

// ----------------------------------------------------------------------------
uint8_t mcp2515_read_status(uint8_t type);

// ----------------------------------------------------------------------------

uint8_t mcp2515_init(uint8_t speed);

// ----------------------------------------------------------------------------
// check if there are any new messages waiting
uint8_t mcp2515_check_message(void);

// ----------------------------------------------------------------------------
// check if there is a free buffer to send messages
uint8_t mcp2515_check_free_buffer(void);

// ----------------------------------------------------------------------------
uint8_t mcp2515_get_message(tCAN *message);

// ----------------------------------------------------------------------------
uint8_t mcp2515_send_message(tCAN *message);


#ifdef __cplusplus
}
#endif

#endif	// MCP2515_H

 

I have the oscilloscope with Decoding option. Besides the fact, that I got the scope yesterday and I have get used to it, I also don't get a clear signal from the SPI lines at the moment. :/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
Again, a picture would help us help you!

Mission: Improving the readiness of hams world wide : flinthillsradioinc.com

Interests: Ham Radio, Solar power, futures & currency trading - whats yours?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What picture you'd like to see? Schematics, 'Test setup', graphs and a picture of the PCB are online. Have I missed something?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The *.h file has anything necessary for the caller program to compile. There is a *.cpp (google led me to) or a *.c file, with the same name, which countains c(++) and in which I intend to put debugging instructions.

In your case, it is a *.c -> cannot use Serial.print to debug (could find the 1rst place, in line 175 where an error could be detected and a message would be interested). According to Murphys law, seems worse than I feared : needs some program manipulations, which add typos and horrors.

 

Remains SPI : can you display as hexa what is on MOSI line / MISO line (that would be the best solution, if your scope is smart enough to function as a logic analyser: it would be wise to verify it can do it).

Else, if it cannot be used as a logic analyser : are there pulses on the CK line? MOSI line?

Can you manage with the trigger mode (natural trigger would be !CS; lines to check would be CK,  then MOSI).

 

Edited : Google told me Siglent Siglent SDS1104X-E is a (very nice) *mixed signal* oscilloscope. I bet it can decode SPI ... and , once you know how to use it, you will think it is very useful.

Last Edited: Wed. Jun 13, 2018 - 01:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, the scope is capable of. The decode option is present.

But I don't see any pulses on the SPI lines. For me it looks like there's only +5V and GND.

 

I've hooked up the scope and get the following graphs.

 

For VCC, Reset, CS, MOSI and INT I get this (+5V):

 

 

And for MISO and SCK (GND):

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

https://www.gammon.com.au/spi

shows nice SPI oscillograms, and gives an arduino simple program to generate them (simple enough not to be messed up with MCP programs).

 

I had thought of something much simpler to check SPI : say

#include <SPI.h>
//  simplified from gammon.com.au

void setup (void){
    digitalWrite(SS, HIGH);  // ensure SS stays high

  // Put SCK, MOSI, SS pins into output mode
  // also put SCK, MOSI into LOW state, and SS into HIGH state.
  // Then put SPI hardware into Master mode and turn SPI on
  SPI.begin ();

  delay (5000);  // 5 seconds delay to plug scope.

  // scope trigger should be !SS
}

void loop (void){

  // enable Slave Select
  digitalWrite(SS, LOW);

  // send test string
  for (int i=0; i< 222; i++)
  // clock will be a square wave; 'U' choise leads to MOSI being a square wave, too, whith half frequency
    SPI.transfer ('U');

 // disable Slave Select
 digitalWrite(SS, HIGH);  

 // turn SPI hardware off
 SPI.end ();
 delay(1);
   //loop
}

 

I bet mcp2515 wonot suffer from receiving weird data.

 

in post 3 , you wrote :

"I had to cut two traces (CS and MISO) and swap them, because I had mixed them up. Of course I noticed the mistake only when the PCB was produced - " Just want to know wheteher you detected before power up?

Last Edited: Wed. Jun 13, 2018 - 02:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will test this soon. :)

Thank you very much for your patience and help! :)

 

No, I haven't detected it before - do you think something is broken? Aren't all pins 5V tolerant?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am just curious (I trust much more hardware than software, but trust is subjective).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe I've found the problem! I've tested all connections again and I've found a problem with the soldered wires. One has a short circuit to GND. :/
I will rework them now and tell you the result.

 

Edit: What should I say... I uploaded my CAN sketch again and now the serial monitor shows "ok". :D

I don't know whether I should laugh or cry about it. :D

Nevertheless, I also uploaded your sketch, but I don't see any wave. :/

Maybe my soldered GND 'pin' isn't good enough and/or I still have to learn a lot. ;)

 

Does anyone have suggestions how to design future PCBs, so that the SPI can easily be tested? Holding four probes and do measurements at the same time sounds very tricky. ;)
Even connecting four GND clips doesn't sound so easy for me - all four won't fit onto a 1cm pin. There need to be a better solution. :)

Last Edited: Wed. Jun 13, 2018 - 03:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Show a good photo of your PCB -both sides-. -> makes 2 photos....

else, this link can give you other ideas https://www.avrfreaks.net/forum/...

Adding 4 tiny copper tracks, linking SS, MOSI,MISO and CK to .... 2.54 spaced pins might be doable.

Making a list of each and every pin which should be checked might be a nice idea, too (does only SPI need to be tested?)

maybe this link will give you some ideas

Last Edited: Wed. Jun 13, 2018 - 04:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the past we've simply left thru-holes on signals of interest so you can just solder and off-cut from a resistor lead or similar to make a wire to connect to. Then use clips like these:

 

or maybe more like:

 

Image result for test hooks clips

(not sure what the technical name is?) to make connections to a logic analyser or multi-channel scope or whatever.

Last Edited: Wed. Jun 13, 2018 - 04:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is another way of troubleshooting hardware :

draw the schematics from the existing PCB (the very tedious part) then look at the theoretical schematics. Are things as they should be?

 

I do not know whether OP PCB, once debugged, needs any check connection... (is SPI/ckout testing useful? are they the only pins to be exposed?). If it needs every pin to be exposed, it might become ... a new Arduino clone.