Testing, testing and more testing

[MCUdude]

Since ATtinyCore 2.0.0 never got a release even though it has been in the works for years, not many users have used and tested it. I expect the corefiles contains obvious bugs that have not yet been caught. I don't have plans to add a whole lot of new features to this core, but rather fix bugs and issues when they are discovered. So if you have a chip that is compatible with TinyCore, please give this core a try and report back if you find any bugs/issues. I expect it to be bugs, so please report them once you find them!

Tests	ATtinyX5	ATtinyX4	ATtinyX41	ATtinyX61	ATtinyX7	ATtinyX8	ATtinyX313	ATtiny1634	ATtiny828	ATtiny43	ATtiny26
digitalRead()/digitalWrite()on all pins	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢
analogWrite()on all supported pins	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢
Serial.print() and Serial.read()	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢
analogRead()on all supported pins	🟢	🟢	🟢	🟢	🟢	🟢	⚫️	🟢	🟢	🟢	🟢
SPI master	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢
SPI slave	⚫️	⚫️	🟢	⚫️	🟢	🟢	⚫️	⚫️	🟢	⚫️	⚫️
Wire master	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢
Wire slave	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢
Neopixel library/libraries	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢
Servo library/libraries	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	🟢	⚫️	⚫️
tone() (using timer1)	⚪️	⚪️	⚪️	⚪️	⚪️	⚪️	⚪️	⚪️	⚪️	⚫️	⚫️

🟢 = Works
🔴 = Does not work
🟡 = Partially works
⚫️ = Not present / Not implemented
⚪️ = Untested

[felias-fogg]

We should perhaps also provide various bare-minimum test sketches one can run to test this functionality.
Good idea.

As part of the core?

[MCUdude]

We should perhaps also provide various bare-minimum test sketches one can run to test this functionality.
Good idea.

As part of the core?

I'm fine with this as long as we store the test programs under avr/extras. Do you have any thoughts on how we can test digitalRead in one sketch and digitalWrite in another without having to occupy one or two IO pins for the serial monitor?

[felias-fogg]

MCUdude left a comment (MCUdude/TinyCore#10) We should perhaps also provide various bare-minimum test sketches one can run to test this functionality. Good idea. As part of the core? I'm fine with this as long as we store the test programs under avr/extras. Do you have any thoughts on how we can test digitalRead in one sketch and digitalWrite in another without having to occupy one or two IO pins for the serial monitor? —

We only need a binary outcome, right? So, we could send the program to two different end states (with loops) and run the whole thing with a debugger, testing where it stops. BTW, one can insert BREAK instructions into the test sketch so that you do not have to set them up before starting the sketch.

[MCUdude]

We only need a binary outcome, right?

For digitalRead/digitalWrite, yes. Using a debugger for this sounds like a good idea. Would you mind giving it a try to see if we can make the first row in the table above green?

For other tests like Serial, Wire, SPI, Neopixels and Servo, I think testing it with a "release" build , meaning with -Os and -flto, would be the best option in order to be as close to the real world as possible.

[felias-fogg]

If you only want to stop at some well-defined points, then there is no problem with debugging when -Os and -flto have been activated.

[MCUdude]

I've just started testing, but I find my current hardware debugging setup very flakey. I'm not sure if it's the SNAP or the PyOCD implementation, but I often loose connection with the SNAP when I'm asked to power cycle the board. Also, the DWEN fuse isn't cleared after an ended session, which makes it very difficult (if not impossible) for non-hardware-debug-compatible programmers to gain access over ISP again. Shouldn't the DWEN fuse be cleared (set to 1) when the debug session is done?

[MCUdude]

HardwareSerial for the ATtiny841 works fine when using an external crystal, but the built-in 8 MHz oscillator in the chip I have are way too fast. I had to manually lower the OSCCAL0 register by at least five counts (from 0x29 to 0x24) before I could get reliable communication at 250000 and 1M baud at 5V. Spence is referring to oscillator calibration tuning in his documentation, but I have yet to find any tuning sketch bundles with ATtinyCore.

It is possible to set a calibration value offset in the boards.txt file using-DLOWERCAL=N, and setting N to 5 or more works well for me. Can you test this sketch to see how many counts the OSCCAL0 register needs to be lowered before it will be accurate enough for UART communication?

// ATtiny841, 8 MHz internal @ 5V
uint8_t orig_osccal;
void setup() {
  Serial.begin(250000);
  Serial.println("Hello World!");
  orig_osccal=OSCCAL0;
}

void loop() {
  while (Serial.available() > 0) {   // Check if data is received
    uint8_t incomingByte = Serial.read(); // Read one byte
    Serial.printf("Got char %c and ASCII value %d, orig. OSCCAL0: %x, act. OSCCAL0: %x\n", incomingByte, incomingByte, orig_osccal, OSCCAL0);

    OSCCAL0--;
  }
  delay(1000);
}

EDIT: I just measured the CKOUT signal on pin PB2. My mac applies about 5.25V to the target board, which makes my chip "spot-on" 8 MHz with an OSCAL0 value of 0x20, 9 counts below the original 0x29. When powered from a lab power supply, 6 counts results in a fairly accurate 8 MHz clock.

[felias-fogg]

Shouldn't the DWEN fuse be cleared (set to 1) when the debug session is done?

Not at all (RTFM)! Because of this power-cycle-stuff, debugwire-mode is not left after a debugging session. You have to do that explicitly by issuing "monitor debugwire disable" or "mo d d".

[felias-fogg]

I am working on a digitalRead/Write test suite, which is not trivial at all. Sigh :-(

[felias-fogg]

Spence is referring to oscillator calibration tuning in his documentation, but I have yet to find any tuning sketch bundles with ATtinyCore.

Have a look at my calibration sketch: https://arduino-craft-corner.de/index.php/2023/07/03/calibrating-your-avr-mcu-2/

[MCUdude]

Not at all (RTFM)! Because of this power-cycle-stuff, debugwire-mode is not left after a debugging session. You have to do that explicitly by issuing "monitor debugwire disable" or "mo d d".

Yep, sorry. Your documentation is excellent and on point. I have no excuse!

I am working on a digitalRead/Write test suite, which is not trivial at all. Sigh :-(

I made a crude digitalWrite test sketch that works pretty well. I use a physical LED to observe each pin but it doesn't take much time to check all pins, and I have full control when using the debugger. I haven't looked at digitalRead yet, but It is closely related to digitalWrite, so I would be surprised if a pin could be written to but not read.

Have a look at my calibration sketch: https://arduino-craft-corner.de/index.php/2023/07/03/calibrating-your-avr-mcu-2/

That's quite a read! I'll have to give this a try and recommend this as an option for those who has to use the internal oscillator and also needs it to be accurate. BTW have you looked at the way MicroCore is able to calibrate OSCCAL using UART? Not as sophisticated as your approach, but it works! Nerdralph came up with the method, I just implemented it.

[felias-fogg]

We also need some tests for SPI & I2C. I guess two pairs of simple master/slave sketches will do. The neopixel and servo libraries could simply be tested with one of the library examples. And shouldn't one also check whether the boot loader works in the most common settings (i.e., 1, 8, and 16 MHz)?

[MCUdude]

The neopixel and servo libraries could simply be tested with one of the library examples.

I have a servo and some Neopixels/WS2812B I can try with. I'll update the table when I've done the testing for the chips that I have.

And shouldn't one also check whether the boot loader works in the most common settings (i.e., 1, 8, and 16 MHz)?

I don't think this is necessary. The bootloader is very proven, and gone through lots and lots of testing; both by Stefan himself, but also by me and the rest of the Avrdude team when Urboot was implemented in Avrdude.

A failed upload attempt using the bootloader will most likely be related to an inaccurate internal oscillator, or a hardware issue. Chips with a hardware UART uses a bootloader that has auto baud detection, so it will adjust itself to match the incoming data. The ones without a hardware UART uses a software implementation which has a fixed baud rate. However, you can select a bootloader option that can compensate for an oscillator being too fast or too slow (-5% to +5%).

[felias-fogg]

And shouldn't one also check whether the boot loader works in the most common settings (i.e., 1, 8, and 16 MHz)?

I don't think this is necessary.

Perfect!

We also need some tests for SPI & I2C. I

I2C test is done. Will work on SPI today.