Cant get serial.print() to work on attiny3224

[jonathanmlang]

Discussed in https://github.com/SpenceKonde/megaTinyCore/discussions/1041

^{Originally posted by **jonathanmlang** December 18, 2023} Im using this code: `#include "Arduino.h" void setup(){ Serial.begin(9600); } void loop(){ Serial.print("Test"); delay(1000); }` The serial pins PB2 and PB3 are connected to an oscilloscope. Both pins sit at 5v with no activity at all. What could be wrong? megaTinyCore version 2.6.7 Im using platformio in vscode with this platformio.ini: `[platformio] ; Default build target default_envs = Upload_UPDI ; Parameters used for all environments [env] platform = atmelmegaavr framework = arduino ; Chip in use board = ATtiny3224 ; Clock frequency in [Hz] board_build.f_cpu = 16000000L ; Oscillator type (internal or external) board_hardware.oscillator = internal ; Unflag build flags build_unflags = ; Extra build flags build_flags = ; Monitor port is auto detected. Override here ;monitor_port = ; Serial monitor baud rate monitor_speed = 9600 ; Run the following command to upload with this environment ; pio run -e Upload_UPDI -t upload [env:Upload_UPDI] ; Upload protocol for UPDI upload upload_protocol = jtag2updi ;upload_port = COMx upload_flags = ; run the following command to set fuses ; pio run -t fuses -e set_fuses [env:set_fuses] ; Upload protocol for used to set fuses upload_protocol = ${env:Upload_UPDI.upload_protocol} upload_flags = ; Hardware settings board_hardware.bod = 2.7v board_hardware.eesave = yes board_hardware.updipin = updi `

[SpenceKonde]

Well if you clipped the serial cable, the serial adapter's side of the wires would be high no matter what the other half was doing, since an idle serial port is a constant HIGH, and the RX pin has it's pullup turned on so it doesn't see random gibberish if the wire is disconnected.

So that's not very informative. all it means is that the USART is not both enabled and transmittting or receiving. you know that already. More informative would be to disconnect the serial adapter, and put say, a 100k ohm resistor to ground, from each of tx and rx to ground. TX should remain high if the sketch has enabled the USART (with Serial.begin). We would expect that, with the serial adapter disconnected from the serial pins, and no data going down serial, and that 100k ohm load working against the pullups, that RX would be pulled up to about 100/135ths of the supply voltage assuming we can model the pullup as an ideal 35k resistor (the dynamic resistance stays between 30k and 40k ohms for normal situations. (dynamic resistance = if I increase voltage by 1v, and the current increases by 1A, that's a 1ohm dynamic resistance. Dynamic resistance is context dependent - if the temperature changes or a different process is used or at a different voltage, those could be different). We're rather fortunate that we got a near ideal on-chip pullup).

Does the sketch fail to compile, fail to upload, fail to run, or show other signs of running? During development, always have some mechanism where the chip can do something distinctive if serial is either not in use or is what you're trying to debug.

Can you please post one of the invocations of avr-gcc at minimum? eg,

C:\\arduino-1.8.13_AZD5test\\hardware\\tools\\avr/bin/avr-gcc" -c -g -Os -Wall -Wextra -std=gnu11 -ffunction-sections -fdata-sections -MMD -flto -fno-fat-lto-objects -mrelax -Werror=implicit-function-declaration -Wundef -mmcu=attiny1614 -DF_CPU=20000000L -DCLOCK_SOURCE=0 -DTWI_MORS -DMILLIS_USE_TIMERD0 -DCORE_ATTACH_ALL -DARDUINO=10813 -DARDUINO_AVR_ATtiny1614 -DARDUINO_ARCH_MEGAAVR "-DMEGATINYCORE=\"2.6.10\"" -DMEGATINYCORE_MAJOR=2UL -DMEGATINYCORE_MINOR=6UL -DMEGATINYCORE_PATCH=10UL -DMEGATINYCORE_RELEASED=1 -DARDUINO_attinyxy4 -DUSING_OPTIBOOT "-IC:\\Users\\Spence\\Documents\\Arduino\\hardware\\megaTinyCore\\megaavr\\cores\\megatinycore/api/deprecated" "-IC:\\Users\\Spence\\Documents\\Arduino\\hardware\\megaTinyCore\\megaavr\\cores\\megatinycore" "-IC:\\Users\\Spence\\Documents\\Arduino\\hardware\\megaTinyCore\\megaavr\\variants\\txy4" "C:\\Users\\Spence\\Documents\\Arduino\\hardware\\megaTinyCore\\megaavr\\cores\\megatinycore\\hooks.c" -o "C:\\Users\\Spence\\AppData\\Local\\Temp\\arduino_build_728726\\core\\hooks.c.o"

And wait wait WAIT!

2.6.7?! That version doesn't even compile for more than a third of the devices the core is supposed to support" Since 2.6.7, there have been TWO critical bugfix releases. Did you get anything to work on 2.6.7? I don't think you could have, I think that version was completely hosed.

[jonathanmlang]

Ok just need to figure out how to get anything above 2.6.7 to actually install in platformio. Its fighting me. Doesnt seem to have been ported over yet? Maybe its because Im quite new to all this and I'm missing something obvious. Thanks for replying.

[SpenceKonde]

Please retest with current version. Nothing is expected to work on 2.6.7. and 2.6.7 predates my set of fixes to block compilation when we can tell that an invalid set of -D parameters is being used (either missing a required argument, or two mutually exclusive options, and on Arduino I'm guaranteed that only one of the valid options could be selected. On platform I/O, I've seen "pick one of these options" type defines missing entirely, I've seen people running compiles with two millis timers defined (didn't compile, but was disturbingly close to compiling and producing wacky behavior. , because the platform doesn't do the menus or anything.

The example I showed was a line from a compile with all default options selected on the ide -DF_CPU=20000000L -DCLOCK_SOURCE=0 -DTWI_MORS -DMILLIS_USE_TIMERD0 -DCORE_ATTACH_ALL -DARDUINO=10813 -DARDUINO_AVR_ATtiny1614 -DARDUINO_ARCH_MEGAAVR "-DMEGATINYCORE=\"2.6.10\"" -DMEGATINYCORE_MAJOR=2UL -DMEGATINYCORE_MINOR=6UL -DMEGATINYCORE_PATCH=10UL -DMEGATINYCORE_RELEASED=1 -DARDUINO_attinyxy4 -DUSING_OPTIBOOT

[SpenceKonde]

I dont know anything about pio so I can't comment on the installation process