SOLVED: What could make my Nano just HALT or reset itself?

mindrobots · 2014-03-04 12:08

I've been playing more with my pfth attempting to move the data stack into AUXRAM. As a debugging aid, I built this LED front panel to show the output of a 16 bit trace (the top LEDs don't work yet but the bottom 9 address LEDs do.)

The above is what it looks like running a working pfth in the loop waiting for input.

When I load my pfth with the broken stack, it runs a bit and then all the lights go out. I'm guessing it resets itself since the green light on the Nano goes out also. The other alternative for having no lights is doing a JPM #0 at address 0 - not likely. Cleared memory would give me bunches of flashing lights as it stepped through the NOPs, right?

Any thought what could account for the reset or the halt?

I may know more once my upper indicator LEDs are working.

cgracey · 2014-03-04 12:24

You might need to plug a power supply into the Nano, as the USB power may be inadequate.

mindrobots · 2014-03-04 12:40

cgracey wrote: »

You might need to plug a power supply into the Nano, as the USB power may be inadequate.

Thanks, Chip!

I moved it from my Mac's USB port to a powered (2.6A) USB HUB. I still get the same results it runs through some code and then all lights go out. I'm assuming due to coding errors, the program goes off into the weeds and then clobbers itself? I didn't expect it to be able to reset itself from an instruction execution.

I'll check the HUB, FETCH, GO, COND and JUMP bits out of the trace to see if it sheds any more light.

Edit: I just hooked up those lights. I get activity while it is running but then it stops with no lights and the green light goes out on the Nano. Appears to reset itself.

(I do like my little front panel and the setrace feature, through!)

ctwardell · 2014-03-04 13:20

Rick,

Board does look nice. What value are you using for the dropping resistors?

C.W.

mindrobots · 2014-03-04 13:38

ctwardell wrote: »

Rick,

Board does look nice. What value are you using for the dropping resistors?

C.W.

200 ohm - a tad lower than usual but they came with the LEDs in the pack and I thought it would be rude to leave a conference call to go scrounging in the basement for resistors. I need to check solder joints on the perf board and see if I have something wrong. I may have been distracted by the call.

I'm going to build a better "front panel", it's neat to watch....not sure how practical at this point but it's LEDs, so it's gotta be good!!

(Rick's Law: The value of your day job is directly proportional to the things you can build while on conference calls!)

mindrobots · 2014-03-04 14:33

Ok, the front panel now works with all lights. We can write that off to bad solder joints and bad eyes! Yay! Font Panels are cool!

Now, the original problem still exists. The Nano still appears to reset but it doesn't come back like it does when it is reset by closing a terminal session. The green light on the Nano doesn't blink and then it goes into the monitor, the green light goes out and doesn't come back on until you reset it.

Sapieha · 2014-03-04 14:38

Hi mindrobots.

For me it looks as Stack problems.

That its grown else decrease NOT same 1x1 but in any round it go 1x2 else 2x1

mindrobots wrote: »

Ok, the front panel now works with all lights. We can write that off to bad solder joints and bad eyes! Yay! Font Panels are cool!

Now, the original problem still exists. The Nano still appears to reset but it doesn't come back like it does when it is reset by closing a terminal session. The green light on the Nano doesn't blink and then it goes into the monitor, the green light goes out and doesn't come back on until you reset it.

mindrobots · 2014-03-04 14:44

Sapieha wrote: »

Hi mindrobots.

For me it looks as Stack problems.

That its grown else decrease NOT same 1x1 but in any round it go 1x2 else 2x1

Hi Sapieha,

That's what I've been thinking all along. Most of the stack usage it pretty straight forward - balanced pushes and pops but there are two routines (rollfunc and indexstack) that manipulate the stack (not the pointer but the contents) and I think I have those messed up but I just can't see it. I've been looking at it too long to see it with my own eyes.

I'll start tearing it apart and try to get down to the basics (before it needs those functions) and see if my basic stack works (that should).

Thanks for the feedback!

Cluso99 · 2014-03-04 17:45

I am presuming that you have tried a good program and that works ok?

mindrobots · 2014-03-04 18:02

Cluso99 wrote: »

I am presuming that you have tried a good program and that works ok?

Oh yes, it runs evrything else just fine. The problem is in my one program where I try to use AUXRAM as the data stack using ptrx. In another version, I have set up the return stack to use AUXRAM with ptry, it works great. I shot meself in the foot but I just don't see how.

Some place, I mess up tne stack and just can't find it. The thing I thought strange was the Nano's reaction of resetting.

ozpropdev · 2014-03-04 18:18

mindrobots wrote: »

Oh yes, it runs evrything else just fine. The problem is in my one program where I try to use AUXRAM as the data stack using ptrx. In another version, I have set up the return stack to use AUXRAM with ptry, it works great. I shot meself in the foot but I just don't see how.

Some place, I mess up tne stack and just can't find it. The thing I thought strange was the Nano's reaction of resetting.

Just a thought, you mentioned that PTRY worked but PTRX does not.
PUSHY works in the reverse direction to PUSHX.
Maybe that's the trap?
Brian

mindrobots · 2014-03-04 18:33

ozpropdev wrote: »

Just a thought, you mentioned that PTRY worked but PTRX does not.
PUSHY works in the reverse direction to PUSHX.
Maybe that's the trap?
Brian

POPY/PUSHY/PTRY work for the return stack implementation. Once I figured that one out and got the directions straight it works fine. Then I went on to implement the data stack with POPX/PUSHX/PTRX and it failed. So I thought some sort of stack conflict or collision even though neither stack gets near 128 longs. I went back to the program with just HUB sgacks and just implemented the data stack using PTRX. It fails. I tried it with PTRY, it fails. I mucked about the two routines where I play with the stact not using PTRX, it fails. I'm missing something so I may just go play with something else to clear my head. That's one reason I made the front panel, a hardware diversion.

Thanks for thinking about it.

cgracey · 2014-03-04 18:42

From cog start, PTRX and PTRY are both $00.

PUSHX will write a value to AUX[PTRX++]
PUSHY will write a value to AUX[$FF-(PTRY++)]

PUSHX/POPX/CALLX/RETX all work forward, with CALLX/PUSHX going upwards and RETX/POPX going downwards.

PUSHY/POPY/CALLY/RETY are like their -X counterparts, but the final address used is always XOR'd with $FF (or subtracted from $FF, if you'd rather think about it that way).

Sapieha · 2014-03-04 18:43

Hi mindrobots.
If POPY/PUSHY/PTRY function but NOT ---> POPX/PUSHX/PTRX

Maybe it is question to Chip ---> Can beBUG in POPX/PUSHX/PTRX

mindrobots wrote: »

POPY/PUSHY/PTRY work for the return stack implementation. Once I figured that one out and got the directions straight it works fine. Then I went on to implement the data stack with POPX/PUSHX/PTRX and it failed. So I thought some sort of stack conflict or collision even though neither stack gets near 128 longs. I went back to the program with just HUB sgacks and just implemented the data stack using PTRX. It fails. I tried it with PTRY, it fails. I mucked about the two routines where I play with the stact not using PTRX, it fails. I'm missing something so I may just go play with something else to clear my head. That's one reason I made the front panel, a hardware diversion.

Thanks for thinking about it.

cgracey · 2014-03-05 00:04

Sapieha is right. There is a bug.

The bug causes RETY to read the wrong location in AUX. It reads AUX[$FF XOR PTRY] when it should be reading AUX[$FF XOR --PTRY]. PTRY gets adjusted properly, afterwards, but the read address was wrong.

I was working on this Verilog section tonight to give each task its own PTRX/PTRY pair when I remembered that Sapieha had suggested there might be a bug. In looking at the code, I realized that there was a problem.

This will be fixed in the next release. Sorry about all this hassle.

But THANK YOU for finding this problem!

Sapieha · 2014-03-05 00:08

Hi Chip.

Thanks

cgracey · 2014-03-05 00:22

cgracey wrote: »

Sapieha is right. There is a bug.

The bug causes RETY to read the wrong location in AUX. It reads AUX[$FF XOR PTRY] when it should be reading AUX[$FF XOR --PTRY]. PTRY gets adjusted properly, afterwards, but the read address was wrong.

I was working on this Verilog section tonight to give each task its own PTRX/PTRY pair when I remembered that Sapieha had suggested there might be a bug. In looking at the code, I realized that there was a problem.

This will be fixed in the next release. Sorry about all this hassle.

But THANK YOU for finding this problem!

FALSE ALARM!!!

That wasn't a bug. I just didn't remember how it worked.

I'm checking the assembler for a problem now.....

mindrobots · 2014-03-05 00:23

cgracey wrote: »

Sapieha is right. There is a bug.

The bug causes RETY to read the wrong location in AUX. It reads AUX[$FF XOR PTRY] when it should be reading AUX[$FF XOR --PTRY]. PTRY gets adjusted properly, afterwards, but the read address was wrong.

I was working on this Verilog section tonight to give each task its own PTRX/PTRY pair when I remembered that Sapieha had suggested there might be a bug. In looking at the code, I realized that there was a problem.

This will be fixed in the next release. Sorry about all this hassle.

But THANK YOU for finding this problem!

Great! I'm not going totally crazy, I guess.

Was there anything similar on the PTRX side? Because that seems to be wnere my issues were/are.

cgracey · 2014-03-05 00:53

I looked at the assembler output and it seems to be in phase with the latest release. It's generating PUSHX/PUSHY/POPX/POPY properly. I don't know what the problem is. When I get my version working again, I'll test all these instructions. Sorry about this.

ozpropdev · 2014-03-05 01:21

Oops! Removed wrong code posting...

cgracey · 2014-03-05 01:31

ozpropdev wrote: »

Oops! Removed wrong code posting...

Remember that for RETY, it's going to get the return address from AUX[$FF XOR --PTRY]. So, if PTRY is $41, it will get the address from $BF, or $FF XOR ($41 - 1). At least, that's what it should do.

ozpropdev · 2014-03-05 01:43

This is the code I tried.
RETX returns "A"
RETY returns "B" ? Should be "C" right?

Edit: Never mind! "B" is correct. I don't know which way is up today! (from downunder)

dat

		orgh	$e00/4
		org

		clkset	#$ff
		setsera	config,##80_000_000 / 115_200
		clrp	#90

		wraux	#alpha,#$7f
		wraux	#bravo,#$80
		wraux	#charlie,#$81

		getcnt	ax
		add	ax,delay
		waitcnt	delay,#0

		serouta	#"="

		setptry	#$80   
		rety


alpha		serouta	#"A"
		jmp	#$

bravo		serouta	#"B"
		jmp	#$

charlie		serouta	#"C"
		jmp	#$

config		long	%10 << 16 | 91 << 9 | %10 << 7 | 90
delay		long	80_000_000 * 15
ax		res	1

Cheers
Brian

Sapieha · 2014-03-05 01:48

Hi nChip.

If it reverse AUX that starts at end of AUX - $1FF so.

RETY need have its value from

$40

> Addres after RETY executed
$41

> pointer to RETY

cgracey wrote: »

Remember that for RETY, it's going to get the return address from AUX[$FF XOR --PTRY]. So, if PTRY is $41, it will get the address from $BF, or $FF XOR ($41 - 1). At least, that's what it should do.

cgracey · 2014-03-05 16:26

ozpropdev wrote: »
This is the code I tried.
RETX returns "A"
RETY returns "B" ? Should be "C" right?

Edit: Never mind! "B" is correct. I don't know which way is up today! (from downunder)
dat

		orgh	$e00/4
		org

		clkset	#$ff
		setsera	config,##80_000_000 / 115_200
		clrp	#90

		wraux	#alpha,#$7f
		wraux	#bravo,#$80
		wraux	#charlie,#$81

		getcnt	ax
		add	ax,delay
		waitcnt	delay,#0

		serouta	#"="

		setptry	#$80   
		rety


alpha		serouta	#"A"
		jmp	#$

bravo		serouta	#"B"
		jmp	#$

charlie		serouta	#"C"
		jmp	#$

config		long	%10 << 16 | 91 << 9 | %10 << 7 | 90
delay		long	80_000_000 * 15
ax		res	1
Cheers
Brian

That's right! When I first looked, it looked wrong to me, too, but "B" is correct.

cgracey · 2014-03-05 16:28

Sapieha wrote: »

Hi nChip.

If it reverse AUX that starts at end of AUX - $1FF so.

RETY need have its value from

$40
> Addres after RETY executed
$41
> pointer to RETY

Whenever RDAUXR/WRUAXR/CALLY/RETY execute, the 8-bit address is inversed (XOR'd with $FF).

mindrobots · 2014-03-06 19:45

Ok, Dave Hein found a bug in my code, so now it is working. I still find the reaction of the Nano interesting as it just stopped.

Thanks everybody for your suggestions!

I did get to build a nifty front panel and Chip did find a semi-related bug, so it wasn't a complete loss!

Heater. · 2014-03-06 20:32

So what was it in the end?

mindrobots · 2014-03-06 20:40

Heater. wrote: »

So what was it in the end?

Ground clutter in my brain.

I had convinced myself that a zero test was for the stack pointer itself as opposed to the item just popped off the stack. Once I had convinced myself, I was to stubborn to listen to myself and any counter arguments.

I still have a stack issue but I'm too tired to look at it anymore.

I stiil don't know why the Nano shuts down...I thought it would just amble through memory tryng to execute whatever it finds.

I need to brush more on my assmembler programming and learn more about the P2 but that's the whole reason I'm here.

Heater. · 2014-03-06 21:18

mindrobots,

Ground clutter in my brain.

Ah yes, I get a lot of that around here as well.

I stiil don't know why the Nano shuts down...I thought it would just amble through memory trying to execute whatever it finds.

I guess this is the meat of my question. What makes you think it did not do that?

It would be rather disturbing if the COG really had jammed in some other way.

cgracey · 2014-03-06 22:13

mindrobots wrote: »

Ok, Dave Hein found a bug in my code, so now it is working. I still find the reaction of the Nano interesting as it just stopped.

Thanks everybody for your suggestions!

I did get to build a nifty front panel and Chip did find a semi-related bug, so it wasn't a complete loss!

Actually, I thought I had found a bug in the Verilog, but the problem was that I wasn't remembering how it actually worked. So, there was no bug, in the end - not to say that other bugs aren't likely lurking and will hopefully be discovered before we make the next chip.

If the cog ran onward, executing whatever code it encountered, there's little telling what it might encounter. Shutting down would only take a COGSTOP instruction, of which there are a few in the hub ROM. So, if it executed a lot of innocuous code, eventually exceeding $1FF, it would have started executing instructions in the hub ROM and possibly encountered one of the COGSTOPs. That would explain the behavior.

mindrobots · 2014-03-06 22:46

DOH! Yeah, COGSTOP, thanks, Chip, that sure wou,d dk it!

SOLVED: What could make my Nano just HALT or reset itself?

Comments