Is there support for the JTAGICE3

[septatrix]

In the documentation it is not listed however there are udev rules configured for it:

https://github.com/navnavnav/Bloom/blob/d303a231b4428d757dfb867d685e0f389d237fe8/resources/udevrules/99-bloom.rules#L15-L16

So is the JTAGICE supported?

[navnavnav]

Hi @septatrix,

Bloom does not currently support the discontinued JTAGICE3 debug tool. But if there is sufficient demand for it, I will consider supporting it.

I will leave this discussion open for anyone else who wants to express demand for this. Users can do so by leaving a comment or adding a reaction. If 10 or more users express demand, I will consider it.

Thanks,

[septatrix]

The problem now is obtaining one for testing. I've asked on AVRFREAKS. There are some suggestions there involving asking Microchip if they have any spares lying around. I will give that a go.

Sadly the device I have at hand belongs to my university and as such I am not able to hand one out.
I would be able to expose it to you via USB/IP but I am not sure if this would be helpful to you.

Have you considered asking Microchip if they would upgrade your hardware for one of the newer tools? It would be great if they replaced them with Atmel-ICEs or any other more modern tool. But this may be a long shot.

Sadly they have been rather unresponsive to some of our other inquiries and in their academic program they only advertise a 25% discount so I am rather pessimistic. And our amount surely does not fall within the free sample category :D

If I can get hold of one, then I can implement support for it, but keep in mind, it will likely take a couple of weeks as I have quite a few other changes planned.

Okay. I have not yet looked at the code and do not know C++ but if it is very close to the Atmel-ICE I could try copying that and see how it works out.

As for #23, it will be a while before I get to that.

If we get the JTAGICE3 working in Bloom we might be able to come up with some hacky interim solution like stopping Bloom and uploading using avrdude but first things first.

[septatrix]

There is currently no Tool Pack published for JTAGICE3, but I am hoping there will be at some point - new devices like Dx/Ex need new debugger firmware.

You mean SAM D and SAM E series? We only really use the ATmega644 so that would not be a concern for us.

[xedbg]

You mean SAM D and SAM E series?

I refer to AVR Dx (current) and AVR Ex (future) families. The ATmega644 is ancient in comparison (but I of course understand that academics don't update their material that often, for good reason)

[navnavnav]

I will scout around for a way to get you a unit for testing (no promises at this point).

Thanks @xedbg, really appreciate it.

Okay. I have not yet looked at the code and do not know C++ but if it is very close to the Atmel-ICE I could try copying that and see how it works out.

Earlier today, another user (@maximevince) inquired about JTAGICE3 support (see #32). He managed to make a small tweak to Bloom and confirm that Bloom's EDBG driver works with the JTAGICE3. Because of this, I've decided to build an unofficial release for the two of you. It won't be deployed as an official release until I've been able to test it on my side, but at least the two of you will have something to work with.

I will try to have the unofficial release ready for you either later today, or later tomorrow.

If we get the JTAGICE3 working in Bloom we might be able to come up with some hacky interim solution like stopping Bloom and uploading using avrdude but first things first.

This should work. Bloom was designed to accommodate programming software, so it shouldn't get in your way (if configured correctly). For example, Bloom will automatically disconnect from the debug tool and target, at the end of a debug session. This means any other program can gain access to the debug tool and program the target. Then, when you start a new debug session in GDB, Bloom will automatically attempt to reconnect. This function is configured via the releasePostDebugSession config parameter.

If you do have any issues, feel free to start another discussion here.

[mraardvark]

@navnavnav - please check your mail from avrfreaks...

[navnavnav]

Unofficial build, branched from version 0.8.3, with JTAGICE3 support

Debian package: https://bloom-public-bucket.s3.eu-west-1.amazonaws.com/misc/Bloom-0.8.3-unofficial-jtagice3-Linux.deb

RPM package: https://bloom-public-bucket.s3.eu-west-1.amazonaws.com/misc/Bloom-0.8.3-unofficial-jtagice3-Linux.rpm

If you already have another version of Bloom installed, follow the instructions in the "Upgrading Bloom" section, at https://bloom.oscillate.io/download

To select the JTAGICE3 debug tool, use the debug tool name jtagice3 in your debug tool config:

"debugTool": {
  "name": "jtagice3"
}

@septatrix & @maximevince please let me know how it goes.

Thanks!

[septatrix]

Hmm, that's a different error, and judging by Bloom's log output, it seems that Bloom is now able to perform debugging operations on your Atmega644, so we're getting closer smiley

To my eye it seemed to be the same as in my previous log output but maybe I missed something.

I think you may be using an incorrect GDB build. How are you starting the debug session? Keep in mind that GDB is typically built for a specific architecture. So for debugging AVRs, you'd typically have a binary named avr-gdb. However, GDB can also be built with support for multiple architectures.

• How are you invoking GDB? Through the command line? If so, what command are you running? Is it avr-gdb or just gdb? If it's the latter, can you confirm your GDB supports the AVR architecture?

Yes from the command line, simply avr-gdb.

• What version of GDB are you running (please include the output of avr-gdb -v)

I use the gdb from the official AVR toolchain: GNU gdb (AVR_8_bit_GNU_Toolchain_3.6.2_1778) 7.8.

You should be using a GDB build that is built for the AVR architecture. You don't have to build GDB yourself - there are packages with pre-built binaries that you can simply install. For Debian-based systems, this would be the gdb-avr package. For RPM packages, see https://rpmfind.net/linux/rpm2html/search.php?query=avr-gdb and similar. Be sure to find a recent package for avr-gdb.

I intentionally did not use a version from the repo as these are very new (in comparison to the ancient official versions ^^) and we previously had problems with newer version of the toolchain.

PS: And Debian/Ubuntu stay on the same old version as the official toolchain due to these incompatibilities.

Let me know how that goes. I have debugging working with the Atmega644, so I think you're quite close to getting things working.

Okay, maybe I will try to get hold of a newer avr-gdb version...

PS: Fedora does not seem to have an official maintained package for the debugger part of the toolchain any more (avr-gcc et al still exist). So I guess this will require some manual compilation :D

BTW, you can ignore this error:

[ERROR] Execution on AVR8 target could not be halted post attach - Failed to receive break event for AVR8 target

It's nothing to do with the issue you're having and shouldn't cause any problems.

Okay. However this seems to also result in Insight not stopping the target or is that to be expected?

Finally, can you please send over some information on your OS? What Linux distro are you using? And at what version? I need this information to look into those libGL errors.

Sure. It's "Fedora Linux 35 (Workstation Edition)". Hit me up if you need any more information.

Thanks

I am definitely the one who has to thank you but I will for sure help with providing more info where I can :D

[navnavnav]

I use the gdb from the official AVR toolchain: GNU gdb (AVR_8_bit_GNU_Toolchain_3.6.2_1778) 7.8

Ah, I suspect this to be the problem. TBH, I've not even tested Bloom with that GDB version. I think you'll have issues with any version preceding 10.1. I know that prior to 10.1, there was a very frustrating bug where GDB was treating program memory as SRAM.

I intentionally did not use a version from the repo as these are very new (in comparison to the ancient official versions ^^) and we previously had problems with newer version of the toolchain.

Oh, I see. If you upgrade to 10.1 or later, we should be able to get a working debug session going. We can then deal with any other issues you face after. I'd be happy to help with those. It's possible that those issues you faced previously were due to a buggy GDB server, as opposed to a buggy GDB. What server were you using?

I'm sure we'll get there 👍🏽

[septatrix]

I use the gdb from the official AVR toolchain: GNU gdb (AVR_8_bit_GNU_Toolchain_3.6.2_1778) 7.8

Ah, I suspect this to be the problem. TBH, I've not even tested Bloom with that GDB version. I think you'll have issues with any version preceding 10.1. I know that prior to 10.1, there was a very frustrating bug where GDB was treating program memory as SRAM.

Okay, self-compile it is then :) I am not sure If I will get to it this week but I will keep you updated (not due to compiling but a generally full schedule).

I intentionally did not use a version from the repo as these are very new (in comparison to the ancient official versions ^^) and we previously had problems with newer version of the toolchain.

Oh, I see. If you upgrade to 10.1 or later, we should be able to get a working debug session going. We can then deal with any other issues you face after. I'd be happy to help with those. It's possible that those issues you faced previously were due to a buggy GDB server, as opposed to a buggy GDB. What server were you using?

I'm sure we'll get there 👍🏽

Those problems were mostly with the compiler. The studens do some rather low level stuff (a basic preemptive OS) and the newer version broke all implementations. However using a newer gdb version with an older/stable compiler should still work.

[septatrix]

I was able to steal the binary from archlinux which seems to work for the most part. Attaching and debugging now works! It seems a bit slower that the built-in one from Microchip/Atmel Studio but I might be mistaken.

Now I cannot wait for meta commands like monitor reset and load. Keep up the great work! :)

[navnavnav]

That's excellent news @septatrix!

RE Bloom's performance, keep in mind that the Insight window may be causing some unexpected delays. For example, the memory inspection panel will refresh the memory every time execution on the target is halted. This will only happen if the memory inspection panel is open. If you close it, it won't auto refresh. The same goes for the target registers panel - if it's opened, it will automatically refresh all target register values when execution is halted. This may be causing the delays you're seeing. Try closing the panels you're not using in the Insight window and see if that helps.

To close a panel, just click on the same tool button you clicked on to open it:

Also, just FYI, I received a JTAGICE3 from Microchip earlier today, so I can now begin testing and hopefully publish an official release with support for the debug tool. See #36 for updates on that.

[navnavnav]

Support for the JTAGICE3 is now live in v0.9.0. Download the latest version via https://bloom.oscillate.io/download.

https://github.com/navnavnav/Bloom/releases/tag/v0.9.0

[maximevince]

Ah! Forgot to change the tool name, indeed. Will try again tomorrow!

…

-------- Original Message --------

On Apr 12, 2022, 19:30, Nav wrote: > Unfortunately, that does not seem to work over here. ***@***.***(https://github.com/maximevince) Hmm, that is odd. Are you sure you updated your bloom.json with the new debug tool name (jtagice3)? Can you post the contents of your bloom.json file in here please? > However debugging itself does not work with atmega644 as target and jtag as physical interface with failure to receive a break event. ***@***.***(https://github.com/septatrix) Do you have any other target you can try? Preferably one that doesn't use the JTAG physical interface? If you do, please give that a try with the JTAGICE3 and let me know if it works. I've always found debugging AVRs with JTAG to be a bit unstable with EDBG tools. Not just with Bloom, but with other software such as the MPLAB IDE. Also, can you please post Bloom's debug output here? To enable the debug output, set debugLoggingEnabled to true, in the root object of your bloom.json: { "debugLoggingEnabled": true, "environments": {...} } Thanks, — Reply to this email directly, [view it on GitHub](#30 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AA46ZJ6VC3NQP5IHUZR6LLLVEWXMLANCNFSM5S57XN5Q). You are receiving this because you were mentioned.Message ID: ***@***.***>