PE6 Simulator Bug?

EDP

New Member
PICAXE Editor v6.0.8.11
Windows 10 Pro x64 1511 build 10586.633 on Microsoft Surface Pro 3

Two issues:

1. While a simulation is running, the yellow highlight indicating the current instruction sometimes stalls in one place or doesn't appear at all, making it impossible to follow program execution. I can tell that it's still simulating due to output pins changing state as expected, but the instruction highlighting stops. This usually happens when a simulation is started in step mode (by right-clicking the play button), then switched to run mode (e.g. to quickly get through a lengthy DO loop).

2. I'm simulating a program that uses an interrupt, and when the simulation reaches the RETURN statement at the end of the interrupt, the simulator freezes. There are no GOTOs or GOSUBs in the interrupt to mess things up; it just checks a variable flag, reads a pushbutton switch and toggles two outputs. When the freeze happens, the simulator control buttons all grey out and the program becomes almost completely unresponsive. The only thing it will do is return an error if you try to close the program, stating that it cannot be closed while a simulation is running. The program must then be terminated via Task Manager.

Has anyone else experienced these problems, or are they already known issues?

Thanks.
 

cravenhaven

Senior Member
I have come across a simulator freezing scenario if I have the step rate set too high. I leave it on the default now and have no probs with win10 32&64 bit systems.
 

EDP

New Member
I just tried it with the step rate at default (100 ms), as well as slowed all the way (1,000 ms), and it behaved the same. The instruction highlight freezes after a few steps but the simulation continues to run.

I also tried getting to the end of the interrupt entirely in step mode, and it still freezes the program at the RETURN instruction...
 

hippy

Technical Support
Staff member
Welcome to the PICAXE forum.

Please could you post or attach you complete program so we and others can test it to see if they experience the same as you do.
 

EDP

New Member
I've attached the program to this post. This is my first real attempt at BASIC programming since primary school, 30+ years ago, on the Commodore PET and Apple II. I've done a couple of really simple flowchart programs in recent years, but no coding. So, if you see anything that could be done better, please let me know. I tried to read the manuals carefully as I went along...
 

Attachments

hippy

Technical Support
Staff member
It's quite a complicated program. It seemed to run okay for me but I was just randomly clicking input pins. Can you provide details of exactly needs to be done to get it to freeze.
 

EDP

New Member
Oh yeah, I guess it would help to know what the user inputs are supposed to be, and what it's supposed to do!

It's a pushbutton power on/off switch with integrated programmable 0-10A circuit breaker (CB).

INPUTS:
- Pushbutton on pinC.3. This should be pulled high, active low.
- Analog sensor voltage on pinC.4, read by the ADC.

OUTPUTS:
- Switching MOSFET on pinC.0.
- Power indicator LED on pinC.1.
- CB trip indicator LED on pinC.2.

SUMMARY OF OPERATION:
- When the program starts, Task 0 (user input for current limit) will suspend itself unless the pushbutton is held low.
- Task 1 builds a moving average of current flow to whatever is attached to the output, then compares the average against the user-set limit.
- If the average current flow exceeds the limit, Task 2 (CB trip and reset) is resumed. This immediately suspends Task 1 and disables the interrupt.
- While Task 2 is running (CB tripped), holding the pushbutton for 10 seconds resets the CB, zeroes the current readings and restarts Task 1 from the beginning.
- While Task 1 is running, the interrupt is active, called by pushbutton going low.
- The interrupt checks a Power ON/OFF flag, ensures the pushbutton is held 200ms, toggles the output, resets the interrupt and returns to Task 1.

To duplicate my problem, set pinC.3 high, reduce the analog value on pinC.4 to <100, then run the simulation. This should get you into Task 1's current monitoring loop (check Code Explorer for variable w11 changing). Taking pinC.3 low will call the interrupt and turn on the output (pinC.0 and pinC.1 high). When pinC.3 is returned high, the interrupt is reset and the program reaches RETURN (Line 584). This is where my simulation freezes, the sim control buttons grey out and PE becomes unresponsive. It doesn't matter whether I reach Line 584 via Run or Step; it locks up either way.

When I first start the simulation, the instruction highlight reaches SUSPEND 0 (Line 71) and freezes there. Watching the Code Explorer, it's obviously still running Task 1 in the background, but the highlight isn't following along. Clicking the Break button stops the sim and immediately shows highlight on the active instruction. Clicking Run again restarts the sim but not the highlighting. Using the Step button, instruction highlighting always tracks properly.

I'm attaching another file. It's a table showing the correlation between user inputs and current limit values. This should explain the long list of ELSEIF instructions in Task 0.

Thanks!
 

Attachments

hippy

Technical Support
Staff member
Functionality of the program isn't really that important, only really whether it is working or not.

The first freeze on "SUSPEND 0" is probably that you are only watching task 0. You need a "#SIMTASK ALL" directive to follow the rest.

However, I can replicate what appears to be same as you are experiencing, the highlight remaining on the interrupt RETURN on line 584.

The simulator is not hanging per se because changing the state of C.3 causes execution to again be highlighted.

I would guess the simulator has lost synchronisation with which task is being executed or something like that so it is executing something which it doesn't think it needs to display, leaving the highlight where it is. We will have to investigate further.
 

EDP

New Member
OK, the #SIMTASK ALL directive has solved the highlight problem. That's working perfectly now.

It also seems to prevent the sim controls from freezing at the RETURN on Line 584. However, the sim does still stop there. Then when I subsequently change the state of pinC.3, it un-freezes the sim, but because the interrupt has already been reinstated on Line 583, the change on pinC.3 just re-triggers the interrupt. Once the sim gets into the interrupt, it doesn't seem to be able to get back out.

I'll stand by to see if you find a cause.

Thanks!

Eric

P.S. Is there a way to make PE stop automatically re-opening your last project file every time you launch it? I've unchecked everything under Options | Editor | Use Project Workspaces, but that didn't seem to have any effect.
 

hippy

Technical Support
Staff member
if you see anything that could be done better, please let me know.
My first question would be why you are using multi-tasking if only one task can be running at a time. It would seem easier to just GOTO between mode handling sections.

There seems to be a lot of code which could be replaced by subroutines, perhaps starting with the LED flashing code. That could become something like -

flashCount = ? : Gosub FlashTheLedFlashCountTimes

Button push counting could also probably done using a subroutine.

There are a lot of "IF ... THEN : GOTO ... : ELSE ... END IF" Which could be simplified to single line IF statements, "IF ... THEN GOTO ..."

The huge 'correlate_store_additive:' IF-ELSEIF' table could probably be calculated. That would likely avoid what seems to be an erroneous 65 result when entry is 222.
 

EDP

New Member
My first question would be why you are using multi-tasking if only one task can be running at a time. It would seem easier to just GOTO between mode handling sections.
Hmmm, yes, I suppose so. To be honest, it simply didn't occur to me. I read the manuals as a refresher, saw the SUSPEND instruction and thought, "That'll do what I want." Using one task with GOTO navigation makes a bit more sense. Maybe just one task for current limit programming and one for everything else.


There seems to be a lot of code which could be replaced by subroutines, perhaps starting with the LED flashing code. That could become something like -

flashCount = ? : Gosub FlashTheLedFlashCountTimes

Button push counting could also probably done using a subroutine.
Very good point. I'll definitely go back through the code to tighten it up with better use of subroutines. I was beginning to worry that I'd run out of memory, and if I ever do any bigger projects, I"ll have to learn wrote tighter code. I don't want to be the guy who just grabs a bigger &#956;C when I'm running out of memory...


There are a lot of "IF ... THEN : GOTO ... : ELSE ... END IF" Which could be simplified to single line IF statements, "IF ... THEN GOTO ..."

The huge 'correlate_store_additive:' IF-ELSEIF' table could probably be calculated. That would likely avoid what seems to be an erroneous 65 result when entry is 222.
I'll have to think this one through and re-read the pertinent sections of the manual. I was having problems with the compiler throwing cryptic syntax errors on all of my IF...THEN instructions, and what you see is what I ended up with to stop the errors. When I left ENDIF out, I got errors for too many nested IF statements.

65 is correct for an entry of 222. User entries are split into four groups with a "multiplier" assigned to each, which is stored, then the entry is correlated to an additive value which is also stored. The multiplier and additive are read at startup, the multiplier is multiplied by 256, then added to the additive value (e.g. 65) to determine the 10-bit ADC value that represents the desired current limit. I fiddled around with the idea of storing a lookup table in EEPROM with 10-bit ADC values, but that would have used every single memory location. This uses two (at the expense of all those ELSEIF statements).

If I'm honest, I also couldn't get my head around manipulating two-byte words correctly. Something about the WRITE and READ process, and the bit order, confused me.

Thanks very much for all your help!
 

hippy

Technical Support
Staff member
Part of the IF / END IF problem is probably in trying to put everything on one line, using multi-line IF statements on one line, perhaps not recognising there were one line IF statements which are different to multi-line, for example

Code:
	if PushButton = 0 then : goto tens_2  ;Ensure PushButton released
	endif
Code:
	if Timer_A < 1000 then : goto count_presses_ones  ;Count for 10 sec
	else : goto acknowledge_ones                             ;Time expired
	endif
They would arguably be better as -

Code:
	if PushButton = 0 then goto tens_2  ;Ensure PushButton released
Code:
	if Timer_A < 1000 then goto count_presses_ones  ;Count for 10 sec
	goto acknowledge_ones                                    ;Time expired
 

EDP

New Member
Hmmm, yeah that's what I was struggling with. I read the sections on the different types of IF...THEN statements, and I thought I had the syntax correct, but the compiler wasn't happy with me. I'll give it another try, as I'm sure it was just a case of PEBCAK.

Cheers.
 
Top