Using an old "avrdude.conf" can result in a segmentation fault. #1544
Assignees
Labels
bug
Something isn't working
Comments
|
I tend to think this belongs to But maybe @dl8dtl, @stefanrueger and @MCUdude can chime in and offer their opinion. |
|
I am confident that the combination of "avrdude" itself and the updated "avrdude.conf" that comes with it does not cause this problem. However, be careful when combining "~/.avrduderc". I can only imagine what would have happened if someone had added their own "programmers" and "parts" in the past. (Except for some weirdo who switches home directories and tests different versions of his avrdude) |
|
Whenever I have had a seg fault in avrdude, it was because of make not realising some files were changed (it goes by date, not checksum). Going back and forth between versions using @askn37 Please could I ask you to Then I carry out |
|
@askn37 But you are right. I spotted code that would cause the segfault in the way you describe. I will create a PR for this. Thanks for reporting! |
mcuee
added
bug
I see. Changed the label to bug. |
|
Supplementary exam. |
|
I am sorry. This is an issue in git main caused by PR #1542. I made a mistake and did not test it properly. This will be fixed. |
|
We've found some other strange issues with "dump sernum", but they're a lower priority, so we'll hold off on retesting and reporting until the build issues are resolved. |
@askn37 And thanks a lot for collecting the potential issues in your repo. You are very helpful. |
stefanrueger
changed the title
got it. Segment violation resolved. |
JTAG2UPDI results are negative. Added debug print to check if the condition does not hold at the relevant location. And I got the following information.
please refer. |
wonderful. The issue with jtagmkII_updi not being able to read IO memory is definitely resolved. tinyAVR (P:0) trial resultsAVR_DX(P:2) trial resultsAVR_EA (P:3) trial results from UPDI4AVR(EDIT: There was a mistake in pasting the log, so I replaced the AVR_EA section.) |
|
@askn37 Thanks for testing. Your results look like
The Line 1006 in 2bb36b9 Line 2169 in 2bb36b9 0x2200 rather than 0x1100. Can someone confirm, please?
|
|
Unlike JTAG2UPDI, which uses the device_descriptor structure, UPDI4AVR uses the xmega_device_desc structure. The branch condition to switch is This requires that the byte chunks passed in STK500v2 are zero-based relative addresses. If the address value is doubled, then both the structure and the READ/WRITE instruction can be considered to have the same address. UPDI4AVR was fine in the 6.3 to 7.2 implementation, so this fact suggests a break in compatibility. To double check this behavior you will need another JTAG debugger that uses jtagmkII_set_xmega_params. (who is that? Dragon?) |
|
I will add a little explanation to deepen your knowledge. 'xmega_device_desc', as the name suggests, contains a memory layout enhanced with the XMEGA architecture. It does not pass the model number of the working chip or his NVMCTRL version number. Instead, pass this structure to the STK500v2 adapter. Seeing this, the STK500v2 adapter can deduce which series the target chip belongs to even if it cannot read the target chip's PDI/UPDI. In other words, you can get hints on how to switch the circuits and signal lines required for high voltage control. Regarding UPDI, even if you can't read the SIB from the chip, you can infer the version of NVMCTRL and therefore decide whether to give 12V to the UPDI pad or 8.2V to the RESET pad. In particular, nvm_lock_offset, nvm_user_sig_offset, and nvm_prod_sig_offset are significantly different. Additionally, the SRAM starting address needed to rewrite his USERROW of the lock device can also be obtained through nvm_data_offset. (Since it is not normally used, a dummy value is set.) The problem is that subsequent READ/WRITE instructions mix relative addressing to the structure and absolute addressing from the beginning of the memory map. It's probably an old bug, but it's a convention kept for backwards compatibility. Additionally, terminal mode also has non-uniform addressing. The complex conditional branching in the code below is the result of trial and error to accommodate the differences. At least, this is how I interpreted it from 6.3 to 7.2. |
It is better controlling both sides the FW of the programmer HW and the |
|
test case plan to me Prepare the following shell script -c *** -p t824 -U fuses:r:-:I -U lock:r:-:I -U prodsig:r:-:I Try this 2x2 pattern Two types of configuration files Build the latest JTGA2UPDI main and write it to UNO (mine hasn't been touched in a long time) |
|
| UPDI4AVR was fine in the 6.3 to 7.2 implementation, so this fact suggests a break in compatibility. This may well be. I suspect the root problem is that updi4avr project is (so far) not catered for: AVRDUDE has no way of knowing which unsupported projects utilise which behaviour! Whilst we develop AVRDUDE further we try hard to ensure that once supported and known programmers keep working with AVRDUDE. These are often programmers someone in the team has and that we can test on. We welcome reports on regressions. Also, please note, it is generally discouraged to use outdated .conf files with newer AVRDUDE versions. Always try to use the matching .conf file: AVRDUDE expects it can rely on a configuration model of a part/programmer that matches the code base. Having said this, once you figure out what needs changing in AVRDUDE so that updi4avr keeps working well, feel free to submit a PR. We will try to see if that breaks supported programmers. If it does not, we will consider merging. The best way forward, however, is to make sure that AVRDUDE knows about a project/programmer and has a dedicated |
|
UPDI4AVR also provides upward compatibility with JTAG2UPDI. This means you can safely create a bootloader using "-c jtag2updi". We are also approaching AVR_Dx/Ex, which JATG2UPDI has not followed before. This functionality is available out-of-the-box for DxCore and MCUdude projects. (Their "avrdude" is still old) What I specifically want to do is cross-check whether the old and new "avrdude"(and the pair of configuration files) and their adapters are backwards compatible. Generate a report if any discrepancies are found.
|
|
My Dragon uses the JTAG2 protocol use FW 7. And it seems like the JTAGmkII does as well: |
|
OK, summarising: there are no programmers that use jtag2 for UPDI parts with FW > 6. The only jtag2 programmers with FW > 6 cater for XMEGA parts. So, the following lines Lines 1288 to 1291 in 96b081b
Comments? @askn37 @mcuee @MCUdude [EDIT: OK, for the time being, let's keep using |
|
I'm fine with that as long as it doesn't break anything. In the really old days, the jtag2updi project just used "vanilla" avrdude 6.3 using the |
|
@askn37 Thanks for your thorough analysis. Looks like FWV=7 only happens with PM_PDI parts, and as such it makes sense that the XMEGA parameters are captured and communication, for example the application and boot offsets (unique to XMEGAs). Now, seeing that FW=7 + UPDI does not occur with supported AVRDUDE programmers, which project should have authority to extend jtag2updi? There might well be another so far unsupported programmer that has backfitted AVRDUDE behaviour in a different way. And what do we do if somehow an official Microchip successor project for jtagmkII comes about? I still think it would be better if the updi4avr project submitted a
This is almost certainly a failure of
I have checked posix serial send and receive. |
|
@stefanrueger I only have a mac at hand:
https://gist.github.com/MCUdude/4f6e5609928fda35da15ba3c1797b7d5
https://gist.github.com/MCUdude/dd9e41e04e37cd6168e49b1837f4192b |
|
@askn37 I do not see how eeprom access differs between v7.2 and PR #1538 for FW=7 + UPDI. How so? | reading fuses memory : [...] byte-oriented and absolute addressing is recommended I think this has happened in the last commit to PR #1538. Please check | reading chip silicon revision : Although it is in byte mode with MTYPE_XMEGA_FLASH, nvm_data_offset was already added | dump eeprom : [...] The result will be twice the address. What do you suggest? Please tell us in a git diff. |
|
I think this communication trace feature is very useful improvement to debug low level protocol. The following debug logs are generated using the github action binaries (mingw64 and MSVC64). Usbdev send and reveive (-vvvvv)
Click for full debug log
Click for full debug log |
|
avrdude: Built Version 7.2-20231102 (9c894e1) builting now... 76cbf91: This version incorrectly wrote the EEPROM address value directly in the offset field. 9c894e1: This version reverted to the same behavior as v7.2. It's not a bug anymore. |
|
Serial send and receive in windows (-vvvv)
Click for full debug log
Click for full debug log |
|
Unfortunately I can not test this one. Serial send and receive in windows over ethernet (-vvvv) --- these are the net_send() and net_recv() functions |
|
Usbhid send and receive (-vvvvv) --- one more v the code uses msg_trace2()
Click for full debug log
Click for full debug log |
This is still a disadvantage for me. Can someone clearly explain why the IO data memory bus is configured with MTYPE_XMEGA_FLASH=0xC0? This label is originally intended to refer to the code address bus after In case you forgot, the AVR is a Harvard architecture, so the code address bus (word granularity) and data address bus (byte granularity) are completely different. Please use them with strict distinction. The same is true for PDI, UPDI, and JTAG. MTYPE is a guideline for that purpose. Don't take it lightly! |
|
Just want to add some debug logs with similar testing devices as @MCUdude, but tested using latest PR #1538 under Windows with MSYS2 mingw64 build wth traces.
My debug log. I got slightly newer FW version compared to Hans: You can also see that Click for full debug log for official Arduino Nano Every
My debug log under Windows with MSYS2 mingw64 binary (with libserialport) Click for full debug log for Nano Every ATmega4808
This is my debug log under Windows using MSYS2 ming64 build (with libserialport). Same FW version as Hans. Click for full debug log for a DIY jtag2updi, using a CH340 Uno Clone |
|
One more searial trace for Windows with MSYS2 mingw64 build (with libserialport) using Take note I have to use Click for full debug log for serialupdi with AVR64DD32 |
|
One more usbdev traces for Windows with MSYS2 mingw64 build (with libusb-1.0+libusb-compat-0.1 API) using Click for full debug log using AVRISP mkII and ATxmega32A4U |
@askn37 @stefanrueger The following output is from latest PR #1538. |
I can confirm that AVR Drago uses the JTAG2 protocol with FW 7. But I can not connect to ATxmega32A4U. I remember AVR Dragon has some limitations when it comes to PDI programming. Or maybe my connection is not stable. Run log with latest PR #1538 with trace function, MSYS2 mingw64 build with libusb-1.0+libusb-compat-0.1 (WinUSB driver). |
ATxmega32A4U [Production Signature Row] PDI Address base is $08E0200 (25-bit address 32MiB memory map) Why there? I'm sure the address offset is wrong...
|
|
Since I cannot get my AVR Drago to connect to my ATxmega32A4U breakout board, please help to test your AVR Dragon with your xMega target and see if there ar anything strange (eg: to dump My full debug log for click for the debug log with AVRISP mkII and ATxmega32A4U |
|
I've never thought about it before, but the "part" command doesn't help. In the Xmega generation "x32a4u" example, I would like to know the start address definition for each section, but it does not exist. There is even less information about the UPDI generation. What do "mode", "delay" and "polling index" mean? Where can I change them? Of course they were important to older generations of programmers. I feel a generation gap.... |
|
| How do I know if the reading of io is correct. The following data look suspicious. The
And here the details of the MCU register:
|
|
| the "part" command doesn't help Please! This is a venerable command as old as the terminal introduced at a time when there were only classic parts around. But yes, it is right to say that the AVRDUDE project should probably review the part command and extend it to XMEGAs and UPDI parts as to display relevant properties of these types. @MCUdude, this sounds right up your road? 😉 The same is true for debug messages that ought to be updated with more relevant info (and perhaps consider removal of the repeated headlines). | would like to know the start address definition for each section BTW, you can always ask avrdude: |
|
The If you could give me a list of what should be there, (what what should be removed), I can see if I can create a more useful implementation.
|
Totally agree. |
|
@MCUdude Thanks! Yes, you are right. If it was up to me I would keep the info printed for the classic parts with the exception of
For the
Haha, well spotted! I guess it's the default for classic parts (so parallel unless some bit is set in some flag), and hence this is incorrectly asserted for UPDI parts. Yes, this needs a bit TLC. Thank you for taking that on. |
|
@askn37 This issue will be closed shortly. Let me reflect on some of the things observed:
We tend to talk about undocumented behaviour, when an unsupported programmer sends info back to AVRDUDE that makes it behave in a certain way. When AVRDUDE does not behave like an unsupported programmer expects we tend not to think that this is a bug. This may be unfortunate for the unsupported programmer, but it is not a bug.
A better way to support a new programmer is to submit to the AVRDUDE project a PR for an independent programmer module, eg,
They are important to older generations of programmers! Just because new parts and programmers came along does not mean that all hardware with classic parts vanish in thin air. The AVRDUDE project prides itself with being able to handle 20-year old parts and programmers! |
|
I also agree with you. I have already started gathering information to create updi4avr.c. (I still don't know how to add new files to the project) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As the title suggests, after one hardship, another one.
This issue currently occurs when the following combinations are met:
The issue does not occur in the currently released 7.2.
Discovered OS:
A case where a problem occurs.
For normal operation
Comparison between the two
avrdude_conf_fail.txt
avrdude_conf_good.txt
Additional Information
I mainly use a self-made implementation using "jtagmkii_updi", and that's where I first discovered the problem. Naturally, I had doubts about my implementation at first, so I also tried his jtag2updi for comparison, and it reproduced the problem.
The difference between the two is whether S_MCU_FW is 6 (jtag2updi) or 7 (updi4avr). The former uses "jtagmkII_set_devdescr" and the latter uses "jtagmkII_set_xmega_params". I don't know of any other implementation that uses this with "jtagmkii_updi"/"jtagmkii_pdi". It probably doesn't matter.
Important things
The text was updated successfully, but these errors were encountered: