AVR Freaks

Thank you!

The low prices are a rather unexpected and pleasant surprise.

As I explained, I am unfamiliar with the AVR and various tool sets. My only experience is via pre-built Arduino boards, where you are isolated from the underlying architecture, which is fine for most of my projects.

The official Altera JTAG pods are rather expensive, however it is possible to buy a cheap Chinese clone for $10. Some have had issues with them, but I have used them successfully.

On Ebay UK I found a UK seller of "AVR JTAG Studio USB Flux Workshop". At around $20 it might be worth a punt.

Someone else has listed a "AVR Jtag In-Circuit Emulator Mk-II" for $130. It does however look genuine, nevertheless more than I want to invest, after all I am only helping a friend to port his code.

Now the question is, what software tools are able to use the JTAG pods?

Would any of these tools allow me to generate the full trace of program execution?

Ha ha! I chuckled when I read your reply. Well what I did was use them to brick the Atmega128  dev board when I first started to play with it. I did say I was new to "stand-alone" AVRs (without the protection of the Arduino GUI or built-in programmer).

BTW I did see the fuse you mention, understand that it was for backwards compatibility, and I definitely need to check the datasheet to understand it 100%. It would also be trivial to unset this fuse and see if this fixes the problem. Fingers crossed!

Here are more details for those interested.

The cheap dev board arrived with a "blink" sketch installed, so the LED blinked when powered. I tried a simple serial sketch, but there was no text in the TeraTerm window. So I copied the standard blink sketch and modified it to flash the two LEDs on this board, using "delay(1000)" for a 1 second on/off delay. I compiled in the Arduino GUI and then found the Arduino build folder in my Temp folder and copied the hex file. I programmed the hex using the usbTiny. No flash. Oh hold on I saw a LED go on, but it's not flashing. Waited longer, and saw that the LEDs were flashing on and off just very slowly. In a moment of lucidity, I had an suspicion that this might be a fuse related clock setting, remembering the pain of the PIC16 days and their fuses. Yep the datasheet explains that the chip is normally supplied with internal oscillator and divided by 8, giving me a 1MHz clock rate (external xtal is 8MHz). So my 1s on/off became 8s on/off and I was too quick to misinterpret the result. Not the first time I have to admit 

So Now I needed to program the fuses. Clearly the binary only contained Flash data. I found an online fuse calculator and selected what I thought was an appropriate setting. What was strange is that the fuse values appeared to be inverted (active low?) and I did get a little confused. I was able to  find the magic command line command for usbTiny and I programmed the fuses to enable the external xtal, but nothing. Oh, and now usbTiny can't connect. I appear to have bricked my dev board.   Oops! SO now I was slightly panicking and googled for an answer. I think eventually I found the answer on this forum, which was to connect an external xtal oscillator to the XTAL IN pin. I found an 8MHz oscillator module, wired it up, and connected the output to each of the 3 convenient IC pin socket holes which allow using a different xtal. Connecting to point one, then two, then three, finally the LEDs started to flash, and this time at the correct rate. usbTiny now also was happy to connect. To cut a long story short, after much messing around, trying different "fuse settings" web sites, I finally managed to work out the correct hex value to enable the external 8MHz xtal. Phew! I tried the simple serial sketch again, and this time it worked like a charm. Now I was in a good position to try my friends code to see if I could help him. I did notice the Mega103 fuse setting, but I left it alone. 

So it's all a learning curve, and to be honest I find it fun, sometimes frustrating, but I usually always find a very satisfying when things start to work.

Thank you David, that is a very helpful posting. You might have saved me wasted time and money. I see that SNAPs can be found on Ebay UK for around $50 to $70. A little more than I want to pay, but I'll have a think.

Just FYI. 

I found a UK seller selling as "as new" SNAP module for £20 plus postage. Seemed a reasonable price, so I have bought it.

BTW, I live in the UK. I tried to find a way to edit my location in my profile, but couldn't find where to set it 

This is only a hobby for me, so I tend to avoid manufacturers official programmers, as they tend to be a little pricey. I cheaped out (some time ago) by buying the usbTiny, which until a few days ago, I hardly ever used. I know that there are better programmers, likely costlier, but this cheap programmer has worked for me.

Having said that I do have a genuine PicKit II and III since Microchip were selling them reasonably priced, and the III was heavily discounted when I bought it. If I was planning to work with AVRs more regularly, then even the SNAP at full retail cost I would have considered very reasonable. 

Since I'm helping a friend for a one off "project", then I want to keep any costs as low as possible. My main cost will be the number of hours I spend trying to find a solution to the crash, but since this is a hobby, I will get the satisfaction of helping my friend out, which makes it worthwhile for me, as he has certainly helped me often in the past.

I don't want to sound like I am trying to be awkward and disagree, but I have bought various small and cheap FPGA and CPU dev boards from China. Yes there is a delay in getting the boards, but the saving over buying in the UK (if even available here) is too tempting for me to pass up. I will admit that I can be a bit of a cheapskate! If I was doing this professionally, then yes, I would buy official products.

Thank you! I had actually visited this page, but didn't make the connection. I was assuming that this information was set in "Accounts".

I thought it best to indicate my location, especially since I got told off in another forum for not indicating that I lived in the UK 

So far all the replies have been very helpful. This is a pleasant surprise since I now get nervous about posting in a new forum due to some negative experiences elsewhere. It may not appear so, but I have lots of experience in the micro processor/controller arena, but when it comes to the AVR I am very much a noob 

OK I have made some progress. I will give details in case the methodology is of interest to others in a similar position. This is just my approach, YMMV.

So I wanted to use a technique which I have used in the past, where I run the code using a software simulator and get a full trace of every instruction executed, with memory and I/O read and write information. The (very) large log file can be manipulated using various unix tools to look for unusual activity.

I did some googling and having eliminated various candidates, I came across "simavr" (GitHub link).

So good points were: source code was available if modifications were to be needed; it supports the ATmega128; recent GitHub activity suggesting ongoing development and/or support; advanced capabilities for hooking up peripherals.

Bad points: lack of beginners "getting started" guide; if needing to compile from scratch extra support libraries need to be downloaded.

My debug environment is a Ubuntu machine running in a VM (Virtual Machine) under Windows 10.

I used the software download GUI and installed the "simavr" binary. I copied over the output files from the "arduino_build" folder under Win10. Executing the command in a shell gives basic usage information. The good news is that it can read in Intelhex, so this is perfect because the arduino_build folder contains an Intelhex file. You have to define the CPU type, however the usage does not tell you what this switch is! It is "-mcu <cpu_type>". You also have to give the CPU frequency, but again this usage does not indicate what the  switch is (it's "-freq"). That's a minor quibble, easily fixed in the source. I also copied over my "Blink" sketch and used this as a starting point.

migry@Ubuntu:~/AVR$ simavr -mcu atmega128 -freq 16000000 -ff Blink/Blink.ino.hex 
Loaded 1 section of ihex
Load HEX flash 00000000, 2566

The CPU went to full/half(?)  throttle and nothing happened. I had to hit ctrl-C.

A little more googling explained that this tool can link with gdb (actually avr-gdb). This isn't clearly explained in the GitHub or supplied PDF manual, but information is found in various blogs. It connects via a port (1234) to gdb. This is new to me. Unfortunately I have very rarely used gdb, so I have no idea of even the simplest commands. So a bit of a learning curve, and TBH I was reluctant to dive into gdb. I'm sure that it is an excellent tool, but I didn't persue this avenue. I also had no idea if gdb could give the trace I was looking for. The "simavr" tool does have a trace switch, but when I tried it, nothing changed, and there was no output file. Also the usage does not give a version, so I had no idea which binary version had been installed.

So I decided to bite the bullet and compile the source from scratch. This was a simple download from GitHub. I've "built" tools like this before under Linux. Some go smoothly and some are a nightmare. YMMV. This build/make went reasonably well, but I did have to find the missing libraries and install them, but this required more googling to find out where they were. I should have kept notes, to share with others. Perhaps I will go back and try again in order to create some notes to help others.

This version appears to be called "run_avr" and has quite a few extra options, but still no indication of version. In particular there is now support for input and output VCD (Value Change Dump). You can add traces to be sent to the VCD, but once again the syntax is not clear. I had to dive into the source code to try to figure out what the syntax was and what options were allowed. I'm still not sure. At least "-mcu" now "--mcu" and "-freq" now "--freq" are shown in the usage.

migry@Ubuntu:~/AVR$ ./src/simavr/run_avr --mcu atmega128 --freq 16000000 -ff Blink/Blink.ino.hex 
Loaded 1 section(s) of ihex
Load HEX flash 00000000, 2566 at 00000000
Hello..
Hello..
Hello..
Hello..
Hello..
^Csignal caught, simavr terminating

I hit ctrl-C to stop it. Woah! The output which would go to the serial port, now appears in the shell. Wow! It's working. I did try to add signals to the VCD, but failed miserably, so the output VCD was always empty. When I added the trace option, I was clearly told that this needed to enabled in the makefile and the project re-built. I did so by uncommenting a line in the makefile. This was painless.

Loaded 1 section(s) of ihex
Load HEX flash 00000000, 2566 at 00000000
avr_run_one: 0000: jmp 0x0000a7
avr_run_one: 014e: clr r1[00]
014e: 									SREG = .Z......
                                       ->> r1=00 
avr_run_one: 0150: out SREG, r1[00]
0150: 									SREG = ........
                                       ->> SREG=00 
avr_run_one: 0152: ldi YL, 0xff
                                       ->> YL=ff YH=00 
avr_run_one: 0154: ldi YH, 0x10
                                       ->> YL=ff YH=10 
avr_run_one: 0156: out SPH, YH[10]
                                       ->> SPL=ff SPH=10 
avr_run_one: 0158: out SPL, YL[ff]
                                       ->> SPL=ff SPH=10 
avr_run_one: 015a: ldi r17, 0x01
                                       ->> r17=01 
avr_run_one: 015c: ldi XL, 0x00
                                       ->> XL=00 XH=00 
avr_run_one: 015e: ldi XH, 0x01
                                       ->> XL=00 XH=01 
avr_run_one: 0160: ldi ZL, 0xe6
                                       ->> ZL=e6 ZH=00 
avr_run_one: 0162: ldi ZH, 0x09
                                       ->> ZL=e6 ZH=09 
avr_run_one: 0164: ldi r16, 0x00
                                       ->> r16=00 
avr_run_one: 0166: out io:5b, r16[00]
                                       ->> io:5b=00 
avr_run_one: 0168: rjmp .2 [016e]
avr_run_one: 016e: cpi XL[00], 0x20
016e: 									SREG = C.N.S...
avr_run_one: 0170: cpc XH[01], r17[01] = ff
0170: 									SREG = C.N.SH..
avr_run_one: 0172: brne .-5 [016a]	; Will branch

OK this is exactly what I am looking for! Brilliant! I have a tiny amount of familiarity with the AVR instruction set and architecture, but using the list file from the arduino_build folder to cross reference helped enormously (it shows the source C together with the compiled assembly).

It has taken me a little time to understand the output format, and figure out what are reads and writes, but it's starting to make sense. Since I have the source I can re-format the output if I really need to. So I extracted all the writes and then all the I/O accesses. I used sort and uniq to get a condensed picture of CPU activity.

Now I moved over to the firmware which I wanted to debug.

migry@Ubuntu:~/AVR$ ./src/simavr/run_avr  --mcu atmega128 --freq 16000000 -ff ZZ210/ZZ210.hex 
Loaded 1 section(s) of ihex
Load HEX flash 00000000, 17578 at 00000000
.[2JTechnoloya Teensy Controller.
Version 16-Apr-2022.
r0=65 r1=00 r2=00 r3=00 r4=00 r5=00 r6=00 r7=00 r8=00 r9=00 r10=00 r11=00 r12=00 r13=00 r14=00 r15=00
r16=00 r17=03 r18=01 r19=80 r20=0d r21=00 r22=36 r23=01 r24=f7 r25=02 XL=f8 XH=02 YL=90 YH=03 ZL=65 ZH=67 
Y+00=00 Y+01=00 Y+02=00 Y+03=00 Y+04=00 Y+05=00 Y+06=00 Y+07=00 Y+08=00 Y+09=00 Y+10=00 Y+11=10 Y+12=0e Y+13=10 Y+14=0e Y+15=03 Y+16=00 Y+17=0a Y+18=00 Y+19=0a 
*** CYCLE 49366949PC ceca
Segmentation fault (core dumped)

OK, so this is great. The code crashes, just like it does on the real ATmega128 hardware (both professional kit and also my cheap Chinese dev board). Hmmm, it does appear to crash "simavr" too 

So now I realised something. The latest version of the code supports ".elf" format, and this format of file is also created in the arduino_build folder. Let's try it and enable tracing...

0000: __vectors                 jmp 0x000394
0728: __dtors_end               clr r1[00]
0728: 									SREG = .Z......
                                       ->> r1=00 
072a: __dtors_end               out SREG, r1[00]
072a: 									SREG = ........
                                       ->> SREG=00 
072c: __dtors_end               ldi YL, 0xff
                                       ->> YL=ff YH=00 
072e: __dtors_end               ldi YH, 0x10
                                       ->> YL=ff YH=10 
0730: __dtors_end               out SPH, YH[10]
                                       ->> SPL=ff SPH=10 
0732: __dtors_end               out SPL, YL[ff]
                                       ->> SPL=ff SPH=10 
0734: __do_copy_data            ldi r17, 0x02
                                       ->> r17=02 
0736: __do_copy_data            ldi XL, 0x00
                                       ->> XL=00 XH=00 
0738: __do_copy_data            ldi XH, 0x01
                                       ->> XL=00 XH=01 
073a: __do_copy_data            ldi ZL, 0xd2
                                       ->> ZL=d2 ZH=00 
073c: __do_copy_data            ldi ZH, 0x42
                                       ->> ZL=d2 ZH=42 
073e: __do_copy_data            ldi r16, 0x00
                                       ->> r16=00 
0740: __do_copy_data            out io:5b, r16[00]
                                       ->> io:5b=00 
0742: __do_copy_data            rjmp .2 [0748]
0748: __do_copy_data            cpi XL[00], 0xd8
0748: 									SREG = C....H..
074a: __do_copy_data            cpc XH[01], r17[02] = fe
074a: 									SREG = C.N.SH..
074c: __do_copy_data            brne .-5 [0744]	; Will branch

OMG! It's got even better. I can now clearly see in which function the code is being executed from!

I can compare to the arduino_build list file, which I edit in Gvim.

I'm liking "simavr" more and more! Now I feel that I have the correct tool to allow me to progress the real debug.

I hope this might be interesting to readers, or useful to anyone finding this thread.

David, thank you for replying. I do not want to appear ungrateful for your help and pointers, since I think I am heading in the right direction. I have addressed your concerns below (hopefully).

Yes, we wrote the source code from scratch. It served as a way to help my friend learn to code with C. We have also coded in a defensive manner to avoid standard issue such as array overflow (use of strcpy etc.).

When we compile for the ATmega128 in the Arduino GUI by selecting the MegaCore plug-in we get all the standard files, Intelhex and Elf. I was using the ".elf" with "simavr" in order to get the symbols.

Well it's our code and we know it very well. We (well I forced my friend) to write a test plan for the end of phase#1, and he ran these tests, recording bugs and other issues. I am not a software developer by trade, but I have tried to help my friend work in a more structured way to minimise any bugs as we go along.

When it comes to the Adafruit LCD I2C library(*), I have studied the code, and here I am less comfortable because I am a C++ noob (well possibly more advanced than noob, but I make no claims).

(*)This appears to trigger the crash.

OK. I am using "simavr" as a simulator. It has no GUI, but I actually prefer this.

Please bear in mind, I am not familiar with the AVR world, and so I have no knowledge of the various tools, which AVR experts would use in my position. That's why I posted, so ask for advice. While I can google to find tools, there's nothing like getting advice from experts who can recommend specific tools.

OK thank you for the suggestion. AS7 sounds like the tool I need to use (and learn how to use).

Once I have the JTAG SNAP module, I will certainly install Atmel Studio.

If it already has a simulation capability, then I don't know this.

I will use the JTAG module to stop (real hardware) before the "lcd.print("crash")" line and examine memory which I have identified as relevant from the "simavr" work. I could possibly already do this using "simavr" and connecting/controlling it via gdb, but I was reluctant to go this route, simply because I don't know this tool. Some might criticise me for being lazy and tell me to just learn the damn tool, but I will decide when I am ready to do this, possibly if other avenues don't pan out. I literally just had a play with avr-gdb. It has so many commands (from help) that I am floundering. I will need to find a good YT video to learn the basics.

I am knowledgeable enough to know that the code should port easily. That's an advantage of using the Arduino environment, support code and libraries, they usually have been well tested on many variants of CPU (both Teensy and AVR).

We have been careful in coding, w.r.t. variable types and sizes, only using things like uint32_t, uint16_t, int_8, etc to try to avoid portability bugs, but this is not an area of expertise, so yes there could be problems.

My biggest concern was the difference in the amount of RAM, and initially I thoughts that this was certainly the reason for the crash. I no longer think this. This concern caused us to thoroughly go through the code base and move all string constants to ROM (PROGMEM in Arduino speak). On the Teensy "const char" are automatically put into ROM, but not with the ATmega128 version of the compiler. This required code changes (mainly adding PROGMEM for string constants). We now have plenty of free RAM (~2.5k out of 4k).

Once we #ifdef out the "lcd" module, the code runs, we can operate the VT100-like serial GUI, and the peripherals on the real hardware are all operating as we expect. 

Again initially I thought the bug was in my modification of the Adafruit I2C library (uses software bit bang I2C), but using the original Adafruit library (uses hardware I2C) the crash still happens.

Ironically there is no LCD (or OLED) on the real hardware. The OLED was added to the Teensy version of the project to give some sort of status screen. For the ATmega128 the LCD was wanted only for printing debug messages to the LCD to help during code development. We are now running various tests on the real hardware to confirm that we can operate all the peripherals, and so far everything is working. Basic "mission mode" operation is also working correctly.

My friend felt compelled to develop a Teensy version, in order to bring the hardware into the 21st century and add features which the original hardware (not his design BTW) and software does not support and is unlikely ever to. Certainly the final Teensy code base will not port back to the old hardware, as he wants to add use of SD card, digital audio (I2S) , and ethernet connectivity. My friend intents to release the project for anyone to use. For this reason, and given he admits to being on a big learning curve, we are trying to keep the code as clean and professional as possible.

The port comes from his frustration with the current hardware/software and bugs introduced with every new release of firmware.

I looked on it as a challenge to port our new code base (now at end of phase #2) to the old hardware, just to prove that the old hardware could be re-purposed.

Ok MattRW, thanks for the further suggestion.

BTW previously I was running "run_avr" in another xterm and I was connected remotely from the avr-gdb tool. I wondered whether the crash messed up the stack so much avr-gdb was unable to make sense of the situation?

I tried again using "gdb" (which AFAIK debugs i686 code on the Linux VM), and I was able to use the run command in the way you show, but now when I did the "up" command it was clear that I was in the source of "run_avr", i.e. I was debugging the "simavr" simulator and not the AVR code. Also note after the AVR crash occurs I have to ctrl-C gdb to get a prompt.

migry@Ubuntu:~/AVR/ZZ210V5$ gdb ~/AVR/src/simavr/run_avr 

GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/migry/AVR/src/simavr/run_avr...done.

(gdb) run  --mcu atmega128 -f 16000000  ~/AVR/ZZ210V5/ZZ210.elf

Starting program: /home/migry/AVR/src/simavr/run_avr --mcu atmega128 -f 16000000  ~/AVR/ZZ210V5/ZZ210.elf
Loaded 17106 bytes at 0
Loaded 472 bytes at 800100
.[2JTechnoloya Teensy Controller.
Version 16-Apr-2022.
r0=65 r1=00 r2=00 r3=00 r4=00 r5=00 r6=00 r7=00 r8=00 r9=00 r10=00 r11=00 r12=00 r13=00 r14=00 r15=00
r16=00 r17=03 r18=01 r19=80 r20=0d r21=00 r22=36 r23=01 r24=f7 r25=02 XL=f8 XH=02 YL=90 YH=03 ZL=65 ZH=67 
Y+00=00 Y+01=00 Y+02=00 Y+03=00 Y+04=00 Y+05=00 Y+06=00 Y+07=00 Y+08=00 Y+09=00 Y+10=00 Y+11=10 Y+12=0e Y+13=10 Y+14=0e Y+15=03 Y+16=00 Y+17=0a Y+18=00 Y+19=0a 
*** CYCLE 49366949PC ceca
*** 2ce4: delay                     RESET -1; sp 10ed
*** 2bc0: __empty                   RESET -2; sp 10ef
*** 2ce0: delay                     RESET -3; sp 10ed
*** 2cb8: micros                    RESET -4; sp 10ef
*** 2c88: micros                    RESET -5; sp 10ed
*** 2c88: micros                    RESET -6; sp 10ed
*** 2ce4: delay                     RESET -7; sp 10ed
*** 2bc0: __empty                   RESET -8; sp 10ef
*** 2ce0: delay                     RESET -9; sp 10ed
*** 2cb8: micros                    RESET -10; sp 10ef
*** 2c88: micros                    RESET -11; sp 10ed
*** 2ce4: delay                     RESET -12; sp 10ed
*** 2bc0: __empty                   RESET -13; sp 10ef
*** 2ce0: delay                     RESET -14; sp 10ed
*** 2cb8: micros                    RESET -15; sp 10ef
*** 2c88: micros                    RESET -16; sp 10ed
*** 2ce4: delay                     RESET -17; sp 10ed
*** 2bc0: __empty                   RESET -18; sp 10ef
*** 2ce0: delay                     RESET -19; sp 10ed
*** 2cb8: micros                    RESET -20; sp 10ef
*** 2c88: micros                    RESET -21; sp 10ed
*** 2c88: micros                    RESET -22; sp 10ed
*** 2ce4: delay                     RESET -23; sp 10ed
*** 2bc0: __empty                   RESET -24; sp 10ef
*** 2ce0: delay                     RESET -25; sp 10ed
*** 2cb8: micros                    RESET -26; sp 10ef
*** 2c88: micros                    RESET -27; sp 10ed
*** 2ce4: delay                     RESET -28; sp 10ed
*** 2bc0: __empty                   RESET -29; sp 10ef
*** 2ce0: delay                     RESET -30; sp 10ed
*** 2cb8: micros                    RESET -31; sp 10ef
Stack Ptr 10f7/10ff = 8 
avr_gdb_init listening on port 1234

^C

Program received signal SIGINT, Interrupt.
0xb7fd6d09 in __kernel_vsyscall ()
(gdb) up
#1  0xb7e233f1 in __GI___select (nfds=4, readfds=0xbfffdd9c, writefds=0x0, exceptfds=0x0, timeout=0xbfffdd88)
    at ../sysdeps/unix/sysv/linux/select.c:41
41	../sysdeps/unix/sysv/linux/select.c: No such file or directory.
(gdb) up
#2  0xb7f3c487 in gdb_network_handler (g=0x427cc0, dosleep=dosleep@entry=50000) at sim/sim_gdb.c:800
800		int ret = select(max, &read_set, NULL, NULL, &timo);
(gdb) up
#3  0xb7f3d63c in avr_gdb_processor (avr=0x40b350, sleep=50000) at sim/sim_gdb.c:939
939		return gdb_network_handler(g, sleep);
(gdb) up
#4  0xb7f4046e in avr_callback_run_gdb (avr=0x40b350) at sim/sim_avr.c:290
290		avr_gdb_processor(avr, avr->state == cpu_Stopped ? 50000 : 0);
(gdb) up
#5  0xb7f4057f in avr_run (avr=0x40b350) at sim/sim_avr.c:405
405		avr->run(avr);
(gdb) up
#6  0x0040102e in main (argc=<optimised out>, argv=<optimised out>) at sim/run_avr.c:281
281			int state = avr_run(avr);
(gdb) up
Initial frame selected; you cannot go up.

OK, here's an update. I have found the bug.

I am embarrassed to say that it was a stupid programming mistake in a trivial piece of code which I wrote.

I think this is a classic bug in C, in that I wrote to an array "out of bounds". The first byte following the end of the array was written to as a consequence of the bug in the code.

By chance the memory after the array was used by the "lcd" C++ object. The first byte of this object was corrupted. The first part of the "lcd" object appears to be 2 vectors, which is then followed by the private variables found in the "lcd.h" file. I am unsure as to what these vectors are, however the first appears to point to an array of addresses in ROM, one of which is "lcd.write()". Corrupting a vector causes a nasty crash. Ironically if the memory following the array was used for simple variables, the corruption might have had zero impact and would have gone unnoticed. The fact that a vector was corrupted at least made the CPU go haywire!

#define SR_MAX_PORT 16

...

   for (uint8_t i=0; i < SR_MAX_PORT; i++) 
   {
      output_port[SR_MAX_PORT] = false;     // <=== index SHOULD be i NOT SR_MAX_PORT
   }
   output_port[SR_P1PTX]  = PTX_OFF;
   output_port[SR_P2PTX]  = LED_OFF;
   output_port[SR_P3PTX]  = LED_OFF;
   output_port[SR_P1PLX]  = CTC_OFF;   
   load_serial_outputs();
   

It looks like a cut and paste problem (I probably copied the definition text), in that the array index is the value used in the definition (SR_MAX_PORT) when it should be the loop index 'i'.

The code output_port[SR_MAX_PORT] = false; writes one byte into the memory following the array.

I called my friend using Skype to explain that I had done some debugging and knew where the problem was but didn't yet know why. He said that by chance he had the code open, so I took him to the module where the above source code is, and explained that there was a write which I didn't understand, which looked like accessing the array out of bounds "as we have discussed", when he spotted the bug which I describe above.

After correcting the bug, the code now runs and the LCD is operational on both my dev board (uses hardware I2C) and my friends original hardware (uses the new bit bang I2C library).

For those curious as to how I found the bug (narrowed down the bugs location?) I will make a further posting with more details.

And I apologise for not taking heed of the posters who recommended linting tools.

I will now pursue finding a lint tool and confirming that it would have caught this bug.

I briefly checked in my Linux VM and there doesn't appear to be a lint. Perhaps there is a switch to gcc to get it to do extra checks, making it "lint like" checks?

I just opened the project in Win10 by running the Arduino GUI. I raised the error setting from "Default" to "All", and wouldn't you just believe it ...

I couldn't copy and paste from the Arduino compile output window, neither could I find the log file. Google didn't help either. I guess one of those quirks of the Arduino GUI.

OK, so no need to pursue finding a linting tool. It's already there in gcc!

Just to clarify (FWIW) my PC runs Win10, but I use Oracle VMs to be able to have a Linux (Ubuntu) desktop on the same machine. Some projects related to old retro CPUs and microcontrollers I prefer to do on the Linux VMs, because I like to have all the usual Unix tools at hand and a lot of user code appears to come from a Linux environment (configure/build/make files etc.). BTW I have Unix tools installed under Windows too, including Cygwin64 which I mostly use when I need to use the "find" Unix command.

I received the SNAP JTAG board yesterday, and installed Microchip Studio and MPLABX (IDE and IPE). There are clearly very large and sophisticated tools and I got the impression that to use them efficiently, you will need to invest a lot of time.

Thanks to a YT video I was able to get a simple program working in MPLABX, and after some fighting I was able to program the ATmega128 using the SNAP and I was able to use the debugger.

Again thanks to another YT video I discovered the "arduino" plug-in for MCS7. I was able to get "Blink" to buiild, however the ZZ210 code failed to build due to not finding various include files. I made many efforts to manually update the include search path, but the damn tool kept overwriting my entries, and drove me crazy. I tried to switch off whatever "auto" feature was doing this, but clearly I was unable to stop this behaviour. There are so many menus and options in the menus that it made my head spin. In the end I gave up.

I might offend fans of this software, but I'll simply say "it's not for me". Clearly YMMV.

I fully understand that to get the best out of many software tools, you have to invest the time to learn it. So I can see that someone who is proficient in the use of this tool would be able to use it to debug the kind of bug I had.

At the end of the day we all are free to choose whatever tools and methodology we prefer, even if they are not the most efficient in the eyes of other people. Let's not fall out because we all have different opinions.