What would REALLY improve the A.S. Simulator/Debugger

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

Working on software a few weeks ahead of the board. Of course, I want the software to be as close to the final form, in as many details as possible. Hence, I really don't want to take the Arduino route, and doubly so, since it does not support a real hardware debugger. And, I have, of course, run head-on, into the issue of hardware generated interrupts. UART interrupts. ADC interrupts. TWI and clock/timer interrupts. The whole enchilada. It is really (really really) frustrating and disappointing that the simulator does not support any of this.

 

But, here is what COULD be done. It OUGHT to be pretty simple. Simply make the simulator (at a minimum) so that a bit changed manually in a register in I/O View behaves as though  it is generated by the hardware. Thus, if you manually set RXCO when the receive interrupt is enabled AND global interrupts are enabled, it would generate a receive interrupt. If one of the early statements in the ISR were like data = UDR0;, you could then manually change data into something meaningful for the code to chew on. Ditto, ADC. Ditto most, if not all, of the other hardware generated interrupts. 

 

I think that a lot of users would jump up and down with joy at such an improvement!

 

Cheers and many thanks

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Jim why not spend £300 on a copy of Proteus? I believe it offers pretty much all the simulation of external stimuli that the Atmel simulator lacks
.
Talking of which, do explore its scripting stimuli language. It may offer some of what you require anyway.

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

In the Studio4 days I read about this found it fairly complex and moved on. Maybe it's simpler now in Studio7 !

http://www.atmel.com/webdoc/simulator/simulator.wb_Simulator2_Stimuli.Introduction.html

 

-- Nigel

 

PS Happy New Year's Debugging.

Last Edited: Sun. Jan 1, 2017 - 10:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's not supposed to be easy it's supposed to be comprehensive (well a bit anyway)

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

I suggest that you prototype with Arduino hardware.

Get your proof of concept and look and feel of the software all done with Arduino libraries,  protoboards,  Ebay modules, ...

 

Yes,   you might run out of Flash or SRAM.   Move the project to Mega2560, Zero, Due, ...

 

You can debug with Serial print statements.    

 

If you want to examine low-level hardware,  you can debug with an ATMEL-ICE.   Or even an XMINI-328P.

In practice,  I find a Saleae Logic Analyser is useful.

 

Having got the project operational,  you can design your custom hardware,  pcbs etc.

 

While waiting for the custom stuff to arrive,   you can "tune" the project for less current,  efficiency etc.

You can do much of this in Arduino-ese.    Alternatively,  you can port your working project into C, ASM,  or whatever.

 

You do not need to Simulate external hardware.   You got the Arduino stuff working within hours!   And with real Ebay modules.

 

Proteus might save you hours of work and aggravation.    The licence will pay for itself in any commercial project.

 

David.

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

STK600 would open up the (almost) full range of AVR.

Can use T&M computer languages to drive the generators (signal, UART, SPI, TWI, discretes) and the scopes (logic analyzers, oscilloscopes)

 

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

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

ka7ehk wrote:
Simply make the simulator (at a minimum) so that a bit changed manually in a register in I/O View behaves as though  it is generated by the hardware.
There's the concept of the Board Support Package (BSP) to add a layer between the application and the hardware.

BSP are present in some OS and RTOS.

Sources of AVR drivers for an AVR BSP would be AVR application notes, ASF, Atmel START, and third parties.

AVR BSP on Linux, macOS, Windows?

http://state-machine.com/doc/AN_QWIN-GUI.pdf

...

(page 7)

3  Developing Embedded Code on Windows

...

3.1  Dual Targeting

...

Dual targeting means that from day one, your embedded code is designed to run on at least two platforms: the final target hardware and your PC.

This in turn requires a specific way of designing the embedded software such that any target dependencies are handled through a well-defined interface often called the Board Support Package (BSP).

...

via http://state-machine.com/doc/an.html#Prototyping

The BSP in that QWIN application note has only a few discretes and the LCD interface; there's no ADC, SPI, TWI, UART, etc.

 

P.S.

Had a major annoyance at a job site where the desk's PC was a "great" distance from the target embedded system (about a 10 to 15 minute walk crossing a four lane arterial road)

Created a BSP for the target.

When moved testing from the PC to the target there was only one major defect; it was visual that I'd forgotten the endian mis-match between the MPU and the bus.

[rant]

Do it like our parent's and grandparent's days where the engineers and the technicians are on adjacent floors with a quick walk for each to the other.

[/rant]

 

 

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

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

Will check out the stimulus script. Thanks for the comments. I still think it is a good (and achievable) idea.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

a bit changed manually in a register in I/O View behaves as though  it is generated by the hardware.

That's what I have been using for the past 16 years, could never get my head around the stimulus script.

 

I have so many different boards around that can be pressed into service for pretty much any project (NONE of them Arduino! cheeky ) and as I don't mind getting my hands dirty with vero-board and a soldering iron I can get a prototype ready pretty quickly. Simulator work is almost never done, I start a project with a debugger attached to a real chip.

 

The BIGGEST improvement that can be made in Studio is for it to work reliably, but we have been down this beaten track before.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

John -

 

I actually agree with you.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

ka7ehk wrote:

But, here is what COULD be done. It OUGHT to be pretty simple. Simply make the simulator (at a minimum) so that a bit changed manually in a register in I/O View behaves as though  it is generated by the hardware. Thus, if you manually set RXCO when the receive interrupt is enabled AND global interrupts are enabled, it would generate a receive interrupt. If one of the early statements in the ISR were like data = UDR0;, you could then manually change data into something meaningful for the code to chew on. Ditto, ADC. Ditto most, if not all, of the other hardware generated interrupts. 

 

I think that a lot of users would jump up and down with joy at such an improvement!

 

Cheers and many thanks

Jim

Have you tried it? In the simulator user guide (http://www.atmel.com/webdoc/simu...) you will find the following bullet point:

When possible, the simulator will often allow full read/write access to registers/bitfields even though they are documented as read-only or write-only. One particularly important example of this is interrupt flags. These are often intended to be read-only, but allowing to write them from the simulator allows triggering the interrupt if the hardware is designed such that the interrupt flag is the cause of the interrupt, which is often the case. This feature is important for stimuli generation, e.g., ADC interrupts can be stimulated by means of writing the converted value to the ADC data register and then trigger the ADC interrupt by means of setting the ADC interrupt flag, (both the ADC data register and the ADC interrupt flag are typically described as read-only in data sheets)

 

This is also valid for the IO-view. This has been there for years...

 

Happy New Year,

Jan Egil

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

je_ruud beat me to it!

 

For the simulator, either write dummy functions that set the flag, or modify as needed for the simulation.  Once you have gone as far as you can with the simulator, time to move to real h/w and a debugger.

 

Good luck,

Jim

 

 

FF = PI > S.E.T

 

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

Hmmm, I TRIED that with M328P RXC0 (UART0 receive complete bit in UCSR0A) in the AS7 simulator, without success. Will take another look at it. 

 

Thanks, Jan!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Jim are you using single step (F11) after setting RXC0 bit? It should then take you to the ISR the next step.

 

Reading UDR0, again in single step, will load the value (possibly meaningless) into a register that you can then modify with the correct value before returning.

This is easily accomplished by putting a breakpoint just after reading UDRO to save single steps.

 

You may have do descent into the abyss of ASM view for best results but I'm at home there. wink

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Well, the UART is a tricky one. At some point somebody decided that it was a smart thing to save an address by putting both TX- and RX-data registers at the same location (I actually don't know if that's the real reason, but I can't think of any better...). So even though we have full access to both the RX- and TX-data registers in the simulator, we have only one address. We could put one of them at a spare IO-address (would work fine in the IO-view and with stimuli files), but we figured that would only be confusing. So we went for the less confusing (?) alternative: When you write to the UDR0 address you write to the RX-data register, and when you read the UDR0 address you read the TX-data register. This means that you will not be able to see what you have written, but if you write to UDR0 in the IO-view and then the CPU reads the UDR0 in the next cycle the CPU should read what you wrote in the IO-view. Another result of this alternative is that if you trace the UDR0 register in a stimuli file you will get a trace of all the data sent from the AVR on the UART.

Did that make sense? If not I'll try to make a more readable explanation.

 

-Jan Egil

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

I'm not concerned about that. What I was trying to do is set the RXC0 bit to trigger a jump to the UART Receive ISR. There it copies UDR0 to a local variable. All I have to do is change that local variable to something useful, then let it go. It was that trigger of the ISR that I was NOT getting. Even single step as js suggested. Will review all of the various enable bits to see what might have gotten in the way. 

 

Thanks

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

js wrote:

Jim are you using single step (F11) after setting RXC0 bit? It should then take you to the ISR the next step.

 

There is a "don't-break-in-interrupt-when-single-stepping"-option that you should be aware of...

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

WHAAAAT? New tricks??

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I haven't Studio in front of me right now, but it should be in Tools-> Options->Debugging (?). It might be called "Don't step into interrupt routines while single stepping" or something. Might be worth it to check if it's set as you want it to be.

 

EDIT: Correct location: Tools->Options->Tools->"Mask interrupts while stepping"

Last Edited: Tue. Jan 3, 2017 - 06:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ahhh, that could be it. I will check. Thank you very much. I did have a major project previously where I probably turned that off.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Jim,

 

did you get this to work? I'm facing the same issue where I'm trying to simulate triggering and ISR by setting the RXC0 bit in UCSR0A to 1 in the simulator when the software has been halted. The firmware works on real hardware, so I'm pretty sure I've set all bits correctly...

 

Funny thing is that when I set the RXC0 bit to 1 by clicking the checkbox the UCSR0A register is updated, but as soon as I hit F11 the bit turns off again (indicated in red) and the ISR is not triggered.

 

Things I've checked:

- Uart RXCIE is checked (interrupt is enabled)

- RXEN0 is checked (receiver is active)

- Global interrupt enable bit is set (SREG, bit I)

- function " ISR(USART_RX_vect)" is present.

- "Debug - options - Tool settings - mask interrupts while stepping" is set to False.

 

The code should be fine and working, but I would like to show my students step-by-step as they don't have anyh debugging hardware...

 

With kind regards

Peter

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

Just tried a simple new project using the mega328PB, changed the ISR to "ISR(USART0_RX_vect)" and triggering the interrupt works as expected in the simulator after setting the RXC0 bit . When reverting back to the mega328P and changing the ISR back to "ISR(USART_RX_vect)" the simulating won't work (setting the RXC0 bit seems to work, but when doing a single step or anything else to resume debugging resets the RXC0 bit to 0).

 

I'm using the latest atmel studio available (AS 7.0 build 1188) on Win 10. Seems like a bug to me...

 

With kind regards

Peter

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

Yes, that flag setting in the IDE did fix my problem.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

There is a bug on the RXC bit on the mega328p simulator model. The same bug also affects the simulator models for mega1284p, mega128, mega164p, mega324p and mega644p. Due to reasons the bug is a bit difficult to fix, and currently we don't have a schedule for when it will be fixed. The bug is registered as AVRSIM-299.

 

EDIT: Specifying that it's for the simulator

Last Edited: Thu. Jan 19, 2017 - 10:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Congratulations Peter, you have found a bug in the mega328P simulator model (RXC0 bit not writable from I/O view). This only affects writing it from the Studio I/O view and stimuli, not code running on the target, so it should simulate correctly. We have various issues in the older simulator models that require us to re-do them before they can be fixed (due to change of tools, long story). This is one of them, so a fix may take a while.

 

This is not an issue in the mega328PB model, as you have discovered. The 328PB is supposed to be upward compatible with the 328P (it has additional features like extra USART and timers), so in the meanwhile you can run on the PB even if the code is written and compiled for the P. Just make sure you compile your code for the P, so the compiler will complain if you accidentallly try to use a PB-specific feature.

 

Edit: This approach is complicated by the P and PB having different signatures, so you may have to revert to an external makefile to make it work.

 

Regards,

roland

Last Edited: Thu. Jan 19, 2017 - 03:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR BSP on Linux, macOS, Windows?

Atmel Packs

XMEGAE

http://packs.download.atmel.com/#collapse-Atmel-XMEGAE-DFP-pdsc

...

1.2.51 Added linux simulator models.

...

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