Call for help - AVR IS debug

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TL;DR Could someone help me sending debug traces of the AVR instructions
(attach an AVR chip model, instruction, registers before/after, PC before/after,
SREG before/after) or donate a debugWIRE-capable hardware?

 

I've been working on a digital simulator and NGSpice library with AVR8
microcontrollers for a while. There were two bugs in a decoder of the AVR
instructions I've discovered and fixed recently thanks to the real-world
firmware simulated.

 

This is why I'd like to ask you for help. If you've a working firmware for the
AVR 8-bit MCU and can attach a debugger to the silicon to trace assembler
instructions, so please write down:

  • AVR model;
  • an instruction (hex value is enough, like 0x1b28);
  • affected registers before/after;
  • PC before/after (hex value is enough);
  • SREG before/after (hex value is enough).

and send it to the MCUSim mailing list, create an issue or post it here.

 

Atmel provided a great documentation and an Instruction Set Manual, but I'd like
to have traces from the silicon directly to be able to write unit tests for
the decoder. It's a bit better then guessing how it'll work on real hardware.

 

Thanks.

 

This topic has a solution.
Last Edited: Mon. Jun 24, 2019 - 01:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You do know you can install AS7 and test the behaviour of every last opcode in that as it already has a totally accurate simulator (accurate for the core CPU instructions I mean)? How does randomly picking the odd opcode sequence from real-world apps actually help the rigorous process of bounds checking all the opcodes in unit tests?

 

In fact to produce such a set of unit tests what you really need is a sim that can easily be command line driven - try googling "buserror avr simulator". You could compare behaviour side by side between that and your own sim.

 

(of course you could just use the whole thing "as is" and save yourself a lot of time ;-)

Last Edited: Mon. Jun 24, 2019 - 10:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's why I mentioned real silicon instead of the existing instruction set simulators, but I didn't know about a simulator in AS7. I just hope it's close enough to the real chips.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dsalychev wrote:
I just hope it's close enough to the real chips.
They use the same descriptive meta language for both the chips and the sim so, yes, I think Atmel/Microchip will 100% guarantee the AS7 simulator.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which meta language are you talking about? Is it something widely-available or just their intellectual property? Thanks for the response, anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rats, the other day morten or je_ruud from Atmel (who both work on AS7/Simulator/etc) actually posted a link to the tool they use to convert the chip models into the simulation DLLs but can I actually find it now that I want to??

 

I'll have a look through "history" and see if I can find it...

 

EDIT: nope, I've tried every kind of search and I've looked through the last few weeks of pages I've visited (because I know I followed the link when it was mentioned) and I cannot find the post so I guess you'll have to wait for someone from Atmel to remind us what it was.

Last Edited: Mon. Jun 24, 2019 - 01:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see. That could be useful, but don't spend much time digging into the history. I'll try to find something useful on my own.

I simply assume AS7's instruction set simulator as a reference implementation until a problem appeared there.

Thanks for your help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you'll have to wait for someone from Atmel to remind us what it was

It'd be great to have a response

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Wow, I finally found the post I was thinking of:

 

https://www.avrfreaks.net/commen...

 

So the AS7 simulation DLLs are created from RTL (VHDL) using:  https://www.veripool.org/wiki/verilator

 

What I guess they aren't going to do is make the VHDL public as that is their main IPR but it is a guarantee that the simulation will be 100% accurate.

Last Edited: Mon. Jun 24, 2019 - 01:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I'll mark your response as a solution.

You've shown me a new reliable source of information regarding AVR instruction set besides datasheets and IS manual.

Brilliant!

 

btw, I'm still struggling to create an NGSpice-ready library with AVR models with not only IS simulation, but peripherals also. Have you seen something like this already available or discussed?

Last Edited: Mon. Jun 24, 2019 - 01:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only things that come close with peripheral simulation (that I know of) are two things:

 

1) Proteus VSM from Labcenter which not only has good CPU simulation but knows how to simulate all kinds of external circuitry too. It is fairly costly around the €300 mark though

 

2) in the good old days of AS4 there was "Hapsim" which was an add on that actually "hacked" into Atmel's simulation DLLs and then added simulation of a limited number of peripherals (each issue of AS4 therefore needed a new issue of Hapsim). This was great if you wanted to have some LEDs , 7segs or an HD44780 LCD (also Serial terminal) but it was not a very accurate simulation so you could drive an LCD or a terminal at whatever speed you chose and they would still work. In Proteus on the other hand it'll tell you things like "your LCD 8bit to 4 bit mode switch is not delaying long enough" or "your UART/serial terminal is not operating at the 9600 baud you think it is". That kind of professionalism is what costs the money.

 

(in days gone by Proteus was shown to have the odd simulation flaw too but I think they are very good at supporting and fixing things so I think it's pretty good these days - one day I may be tempted to get a copy just to see how good it is).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They use the same descriptive meta language for both the chips and the sim so, yes, I think Atmel/Microchip will 100% guarantee the AS7 simulator.

 

That's amazing, never would of thunk it.  I always assumed they handed a summer intern a datasheet & said "create a simulation of all this & have it ready before the end of summer."

 

====

Not sure about Proteus...is that something that is mostly used outside of the US?  

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


avrcandies wrote:
is that something that is mostly used outside of the US?  
Err no - it's as international as everything else on the internet:

 

 

I think that page may even auto adjust the currency display depending on where it thinks you are viewing it from (I was connected to a VPN in USA).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dsalychev wrote:
... or donate a debugWIRE-capable hardware?
Likely can locally or regionally source the required hardware 

debugWIRE via USB UART | AVR Freaks

though the following is a deal :

ATmega328PB Xplained Mini

 

Most XMEGA have four additional instructions (due to USB DPRAM) so would add to your setup a PDI debugger (Atmel-ICE, or, etc)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The AS7 simulator is more than just an IS simulator.

When we create the simulator models we generate it from all the synthesizable (digital) parts of the device, while the non-synthesizable (analog) parts are replaced or stripped away. This means that fully synthesizable peripherals, as timers, event systems and USARTs are complete and cycle accurate.

Other peripherals that consists of an analog part, like ADC, is only partly supported. All the digital pieces are present in the simulator, like registers and logic. For the ADC this means that you can start an ADC conversion, and the conversion will be done at the correct cycle, but the ADC result register will be 0. This can be solved by setting the ADC result register yourself using a stimuli input like the IO-view in AS7.

If you want to use USART RX you can toggle the RX pin to transmit data to the simulator model, but it's probably more convenient to write the byte to the data register and trigger the interrupt by setting the interrupt flag (writing '1' to it).

 

The API for the simulator models, and a gdbproxy implementation, can be found here:  https://github.com/avrsimulator/gdbproxy

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's nice to have such accurate simulator with the digital parts actually, but what if I want to "wrap" it to the NGSpice code model library to use within a simulated circuit based on MCU?

That would save me an enormous amount of time.

The API for the simulator models, and a gdbproxy implementation

It's supposed to use a GDB as a client to connect to the remote target to use the simulator models, isn't it? Is there any way to link agains a library with these models, for example? Is there such library at all?

 

EDIT: It looks like you provide a set of the model libraries (one per chip?). Is it possible to download them separately or get their sources and use in the open source project?

Last Edited: Tue. Jun 25, 2019 - 09:46 AM