… I don’t get any further test output after line 56: Serial.println(“ESP32 Thing Plus Test”);
I have tried running this with and without an SD card installed … also tried on both new boards.
Any suggestions?
Other test scripts seem to work like the Fuel_Gauge. Going to try whittling down the tested features to see if it’s hanging on just one library/feature.
However, is this complete unit test supposed to pass on a default, new board?
I just ran a few test on one of mine. If you run the SD or the fuel gauge test they work (fuel gauge ?). Note that in the unit test both of those are within the EEProm test so that probably is the problem. I got no print outs from any of those test but I did get the LEDs doing their thing.
Note my posts on other ESP32 issues. I see a problem with their testing and test programs when t comes to the ESP32. The fact that it runs FreeRTOS takes everything to a new level.
I soldered male headers to one of mine and then soldered female headers to a pin grid with another set of female headers one space over and connected the inner and outer female headers with short wires. taped cardboard to the back and now I have access to the SD card and all the pins.
Good idea to try the board settings. I have been using “ESP32 Dev Module” … wasn’t sure how to generate text settings so here’s just a screenshot of the (default) options …
It looks like you are using the def I am. Not sure why it doesn’t work.
I work on a Raspberry Pi (4B8) and I have been experimenting - looking at how the boards are defined. Tried editing the def an list and did get a listing for the Thing Plus C but the edited pin file (or something) is not working.
I’ll try anything else I can think of (running out of ideas).
I realize this product line “doesn’t come with any guarantees” but if it won’t pass its own unit tests (directly) out of the box I’ll request new boards to try.
Normally I’d just switch to another board but I really like these specs.
If the tri color LED is changing color it is not a defective board. The test program DOES NOT TEST the SD card or the fuel gauge, or it is just not reporting it. Run the SD and fuel gauge test sketches by themselves and see.
I have now modified a couple files and can now select the ESP32 Thing Plus C from the SparkFun board list.
I am not having any problems with any of the 3 boards I have.
The only example code that doesn’t work as expected is the unit test. I am not sure of the numbers returned by the fuel gauge example.
I am working toward communication by WiFi between 2 ESP32 boards using both cores of each board. In some test I use a Thing Plus C with no problems. Even one that does not much with the unit test.
If you get into using tasks and dual core, setup and loop run on core 1 with loop being a task. Had some fun with that tonight.
Yes I can see how these two cores will be fun trying to manage timers/triggers separately from the work!
I noticed these cores have an option for verbose debugging and turned that on. Here’s what I get now over the serial port when running an SD card test …
I am a mechanic who just tries at programming. When I have tried the unit test I get no printout about the SD card but when I just test the SD card it is OK. on the unit test I do get the color LED doing it’s thing and as that is after the fuel gauge and SD card test that tells me it is a code problem with the unit test.
On dual core programming I have a sketch that read a BME280 in one core and displays the results on the MicroMod Input Display using 3 windows. Sequence of code matters as I have had to move things around to get what I want.
Who ever wrote the the program missed the first rule of testing, test the test! You are trying to get a result that is not going to happen. I have no clue why anyone would run test inside a test. Also if you look at the functions for testing the fuel gauge and SD card they are not going to return expected results. Why the print statements are not working probably has to do with the conversion from the Arduino EEPROM to FreeRTOS.
Give up on it or rewrite the EEPROM test, and the fuel gauge and SD card test too.
@figital - the unit test is meant for internal testing of units before they ship. They are not meant for general users. We use EEPROM to mark a board as tested or not so we can control what errors are shown to the user since firmware is still loaded on the board when you receive it. We don’t want to display 'BOARD FAILED!!" or some other scary output when the board is perfectly fine but doesn’t have all the necessary inputs/outputs attached to complete our internal tests.
Avoid the unit test. There are example sketches to get you started. If you’re concerned about the SD card working, checkout the SD_Test sketch.
Sounds like you’ve got all the right settings tho:
ESP32 Dev Module is correct
CS is pin 5
SD_Test should output the following. Be sure you’re using a <32GB card. Make sure it’s formatted with the ‘SD Formatter’ utility (https://www.sdcard.org/downloads/formatter/) from the SD association. If you’re still having problems with reading SD cards definitely let us know and we’ll get you a replacement board.
I switched to an older SD card that was 16MB (instead of the 64MB versions I’ve been using for years).
Seems to work like a charm now. Thank you both so much for the suggestions and help!
Might have tried that earlier but it looked like those tests think they can detect the existence of an SD card slot without a card in there.
if (cardType == CARD_NONE) {
Serial.println("No SD card attached");
}
Perhaps some other library or board may do that (which would certainly be handy). Now that I’ve got basic functionality I’ll fiddle a little more with the API(s).