Can't work out what is wrong with my PCB design or code.

[Jackster]

I have a custom PCB based off an Arduino Nano (made by me) as well as some code written by a freelancer.


This project has worked fine for 2 years but since early this year, when I had to buy in new stock of pretty much everything, nothing has worked.
I had to get new stock of the ATMega328p, FTDI USB to Serial, caps, crystals, wifi boards and even PCBs.

There was an issue with the new batch of PCBs. Basically the pads for the wifi board were so close to each other, they were practically touching.

But we bought new boards that did not have this issue and still the boards did not work.
At the same time, I did have to buy new 328p, FTDI, crystals and wifi boards as I was out of stock.
So there were a lot of variables that changed.

The main issue is that the code will run for a few mins then stop.
Re-powering the board results in the code running once but then stopping.

I am not a programmer, and not very good at PCB design but what we had worked for a few years.

I am looking for someone to help work out what is wrong with my project.
This is a commercial project. So the code and the design are all not publicly available.
I am also broke so can't afford to pay top price to get this sorted.


Some components I use (to get an idea of what is involved).
ATMega 328p
FTDI FT232RL
TM1637 LED display driver
eByte E01-ML01SP4 Wifi board
PWM distance sensor


I am based in the UK and ideally would like to work with people in the UK as I need to get this sorted asap.

[6v6gt]

I'd look at power issues in this case. Software issues, things like excessive heap fragmentation, signed integers getting too big. etc. etc. are unlikely if it all worked before.
I guess you are running the eByte E01-ML01SP4 (wireless not wifi ?) at 3 volts. Interesting would be to know where its power is derived. If it is the FTDI chip (as in the original Nano design) that is a likely problem.

If you have based the design on a Nano together with a wireless module (NEF24L01 based) I guess there is nothing so special about your (hardware) design which would prevent you publishing it here.

[Jackster]

I'd look at power issues in this case. Software issues, things like excessive heap fragmentation, signed integers getting too big. etc. etc. are unlikely if it all worked before.
I guess you are running the eByte E01-ML01SP4 (wireless not wifi ?) at 3 volts. Interesting would be to know where its power is derived. If it is the FTDI chip (as in the original Nano design) that is a likely problem.

If you have based the design on a Nano together with a wireless module (NEF24L01 based) I guess there is nothing so special about your (hardware) design which would prevent you publishing it here.

Ill double check the power but I ruled it out last time. We use USB for testing and it has been fine with other stuff.

Correct, wireless not wifi.
I use a dedicated 3.3v regulator with a decent cap for that part.

I could probably publish the schematic publicly. Ill work on that now.

[Jackster]

Here is schematic
https://i.postimg.cc/fZgJk3fH/Capture.jpg

Trying out some nRF24L01 examples to see if I can get the wireless to work. Should indicate if there is an issue with the boards?

[Jackster]

Okay so I found some of the code that we made prior to adding the wireless to it.
It runs fine.

(current 2019 code)
In the RF24_config.h there is "#define FAILURE_HANDLING".
I commented it and the code is now running. So we can pretty much pinpoint our issue being the wireless.

Now. This could be the wireless module or it could be my PCB/components.

Going to hazard a guess it being the PCB or components as the issue came around the same time we bought in new stock of the PCBs and the support components such as regulators and capacitors.


[edit]
In the user manual I have just noticed this..

I power my ATMega328p with 5v, does this mean the IO on it is signalling at 5v?

[edit2]
Just checked a few of the signal pins on the board and yes 5v. Guess they want ~3v.

[edit3]
Moved the ATmega328p to 3.3v and still no luck. But I will fix this issue in a revision.

[6v6gt]

I'd have expected to see more dedicated decoupling capacitors around the voltage regulators. I can't say that is the problem but it will always be issue in troubleshooting if it is not done correctly. See the data sheets for example decoupling circuits.


The NRF24L01 (on which your wireless device "eByte E01-ML01SP4 Wifi board" appears to be based) has 5 volt tolerant pins, although the maximum power voltage is 3.6 volts.

The problem with the ATmega328P running at your suggested 3.3 volts is that it is then "overclocked" if you still run it at 16 MHz. If you change the crystal (or is it a resonator ?) to 8MHz to stay in specification, then you need to install a 8MHz version of the bootloader. There are, though, other tricks that you can do like dynamically lowering the clock speed to get round this.

If commenting out what appears to be the radio's failure handling routine allows the whole thing to work, then it could be that this part was not well tested and problems only show up in certain radio failure error cases. Maybe you have to add some debug statements to find out what error is being detected / badly handled.

[Jackster]

I'd have expected to see more dedicated decoupling capacitors around the voltage regulators. I can't say that is the problem but it will always be issue in troubleshooting if it is not done correctly. See the data sheets for example decoupling circuits.


The NRF24L01 (on which your wireless device "eByte E01-ML01SP4 Wifi board" appears to be based) has 5 volt tolerant pins, although the maximum power voltage is 3.6 volts.

The problem with the ATmega328P running at your suggested 3.3 volts is that it is then "overclocked" if you still run it at 16 MHz. If you change the crystal (or is it a resonator ?) to 8MHz to stay in specification, then you need to install a 8MHz version of the bootloader. There are, though, other tricks that you can do like dynamically lowering the clock speed to get round this.

If commenting out what appears to be the radio's failure handling routine allows the whole thing to work, then it could be that this part was not well tested and problems only show up in certain radio failure error cases. Maybe you have to add some debug statements to find out what error is being detected / badly handled.

Thanks for the info.

I am not a programmer so a lot of this sort of work is above my pay grade. But I will look into it.

I do think we have a hardware issue here.
The thing is, it worked before we ordered new PCBs and components.
(no changes were made to the PCB gerbers)

The schematic is from a Arduino example on CircuitMaker.
I have purely added and removed what was needed and not needed. As far as I am aware, that schematic bar the added/removed components is how the power is done for the Nano.

Rather than operating the ATmega328p at 3.3v, ill just put resistors in line with the wireless module as somewhat suggested by the user manual?