Not my first post on crazy voodoo wasting precious time, like it happened some time ago
This time, things are different. I'm working on the uRADMonitor model D
, to summarise it is 60x110cm board with an Atmega2561, a 2500mAh battery, two inverters based on LTC3440 for 3.3V / 5.0V used independently, a TP4056 battery charger, a DS1337 RTC (I2C), an EEPROM (I2C), a FT232 USB2Serial, a software configurable high voltage inverter with multiplier (configured for 480V), a microSD slot (SPI), a NEO6M GPS (UART), a ESP8266-ESP03 Wifi board (UART), a Bosch BME680 (I2C) and a Sharp gp2y1010au0f and an ILI9341 2.4" LCD (SPI) with touchscreen.
After several changes and revisions:
I finally got to the fifth variant which was good enough. I assembled two PCBs and done all the software: drivers for the various modules and sensors, a fat32 implementation for the sdcard, a gps nmea parser, an lcd driver with a minimalistic library, etc, etc. So everything worked just fine.
I pushed it to production, not before doing some changes to the PCB layout, nothing fancy, just moving the speaker a little and adjusting the size of the SMD pads. So the factory finished the assembly of a few devices, but the test software fails.
Here's the Voodoo part:
1. If my code inits the BME680 (over I2c) and tries to write something to the SDCard, the device will NOT start, nothing, not even some innocent code just writing something on the screen.
2. If I take out the BME680 init code,and the read function, the code can write to the SDcard just fine and all the code works, for all the modules and components.
This behaviour is not happening on my two assembled test units. I suspect the following:
1. Different Atmega2561 with some weird memory issues (unlikely)
2. Code memory corruption (unlikely) - the code is nothing but a collection of personal libraries for all the modules used.
Testing goes slow, as it is done remotely on the route Romania - China factory.
Any suggestions on how could this be addressed remotely?