Author Topic: PIC - getting lost / stuck in data table  (Read 9832 times)

0 Members and 1 Guest are viewing this topic.

Offline katzohkiTopic starter

  • Frequent Contributor
  • **
  • Posts: 378
  • Country: us
    • My Blog
Re: PIC - getting lost / stuck in data table
« Reply #25 on: February 08, 2015, 06:15:31 pm »
Part of what's frustrating to me is that I am getting different results depending on what I do, stepping through the code it seems to work. And especially the fact that it works immediately after programming, but not on POR. That I really don't understand.
 

Offline 22swg

  • Frequent Contributor
  • **
  • Posts: 274
  • Country: gb
Re: PIC - getting lost / stuck in data table
« Reply #26 on: February 08, 2015, 08:15:12 pm »
Stepping through in simulator what values are you loading in 'jump' ?    I will repeat ...In my experience  AD result can be wild value after a POR .
Check your tongue, your belly and your lust. Better to enjoy someone else’s madness.
 

Offline katzohkiTopic starter

  • Frequent Contributor
  • **
  • Posts: 378
  • Country: us
    • My Blog
Re: PIC - getting lost / stuck in data table
« Reply #27 on: February 08, 2015, 09:43:06 pm »
Stepping through in simulator what values are you loading in 'jump' ?    I will repeat ...In my experience  AD result can be wild value after a POR .

0,1,2,3... up through 8. I have stepped through it and 9 gets reset. I have tried all of the above suggestions too, without success. That includes AND-ing 'jump' with 0x0F and padding the table.

Maybe I am missing your point about the AD result. Are you suggesting that the bad A/D result causes a malfunction to PCL, PCLATH, STKPTR or something? If the data is garbage I don't see how that will cause the program to jump somewhere unexpected. There is no computed GOTO during the handling of A/D data.
 

Offline 22swg

  • Frequent Contributor
  • **
  • Posts: 274
  • Country: gb
Re: PIC - getting lost / stuck in data table
« Reply #28 on: February 08, 2015, 09:52:09 pm »
And what if AD returned a jump value of  H'0A or greater say FF ?    Have you got the table to go wrong ? or is just after POR
« Last Edit: February 08, 2015, 09:54:33 pm by 22swg »
Check your tongue, your belly and your lust. Better to enjoy someone else’s madness.
 

Online Andy Watson

  • Super Contributor
  • ***
  • Posts: 2074
Re: PIC - getting lost / stuck in data table
« Reply #29 on: February 08, 2015, 10:03:33 pm »
I may have missed something but the routines db_dn and db_up appear to be called from both inside and outside the interrupt service routine - but I can't see any provision to either deal-with, nor prevent re-entering the same code.
 

Offline katzohkiTopic starter

  • Frequent Contributor
  • **
  • Posts: 378
  • Country: us
    • My Blog
Re: PIC - getting lost / stuck in data table
« Reply #30 on: February 09, 2015, 12:15:41 am »
And what if AD returned a jump value of  H'0A or greater say FF ?    Have you got the table to go wrong ? or is just after POR

AD data does not go into 'jump'. Not sure if we're on the same page here. Ie ADRESH is not loaded into 'jump'

I may have missed something but the routines db_dn and db_up appear to be called from both inside and outside the interrupt service routine - but I can't see any provision to either deal-with, nor prevent re-entering the same code.

Is that a problem? I can make some separate denounce routines for inside and outside the isr. Actually db-up or db-dn shouldn't really be called from outside the isr. I thought that with a 16 deep stack that should not be a problem, but maybe I am wrong.

What do you think are the chances there is something wrong with the PIC? I don't have any extra PIC12f1840 to play with and I'm not sure porting the code to something spare that I do have will prove much.
 

Online Andy Watson

  • Super Contributor
  • ***
  • Posts: 2074
Re: PIC - getting lost / stuck in data table
« Reply #31 on: February 09, 2015, 12:28:56 am »
I may have missed something but the routines db_dn and db_up appear to be called from both inside and outside the interrupt service routine - but I can't see any provision to either deal-with, nor prevent re-entering the same code.

Is that a problem?
Without delving into the detail of your code and system - I don't know. But potentially it could be a problem. You have to consider the possibility that the "normal" db_dn is interrupted and another pass through the routing is initiated by the ISR - the normal routine could find its values changed in an unexpected way!

Quote

What do you think are the chances there is something wrong with the PIC? I don't have any extra PIC12f1840 to play with and I'm not sure porting the code to something spare that I do have will prove much.
If it responds in anyway what-so-ever, I would have thought the PIC will be good. Write yourself the simplest of simple programs (like wobbling one bit on a port) and check that you can program it into the PIC. I would suspect that there is a configuration bit or other setting that has been overlooked.

 

Offline 22swg

  • Frequent Contributor
  • **
  • Posts: 274
  • Country: gb
Re: PIC - getting lost / stuck in data table
« Reply #32 on: February 09, 2015, 11:09:30 am »
I put your code into MPLAB 8 , didn't understand your register directives , but eventually got it to build ( absolute). could not see a problem with the table location in disassembly listing , however you do not initialize  [jump]  with a known value ? Quite possible after a por it is  H'FF going to table = infinite loop ? PCL  099 add w  FF  = 098 [ not 198 ] PCL increments  ... PCL  now back at  099 . .............
Disassembly below
Code: [Select]


   099    0782     ADDWF 0x2, F                   407:       addwf   PCL,f
   09A    34DB     RETLW 0xdb                     408:   outputs dt  0xDB,0x1F,0x3F,0x5E,0x7D,0x9C,0xBC,0xDB,0xFA    ;retlw with value   ;probably sits across page boundary
   09B    341F     RETLW 0x1f
   09C    343F     RETLW 0x3f
   09D    345E     RETLW 0x5e
   09E    347D     RETLW 0x7d
   09F    349C     RETLW 0x9c
« Last Edit: February 10, 2015, 11:07:02 am by 22swg »
Check your tongue, your belly and your lust. Better to enjoy someone else’s madness.
 

Online nfmax

  • Super Contributor
  • ***
  • Posts: 1556
  • Country: gb
Re: PIC - getting lost / stuck in data table
« Reply #33 on: February 09, 2015, 02:44:43 pm »
In absolute mode, you can get the MPLAB 8 assembler to check for page boundary crossings like this (which is a snippet from a P16F877 program I wrote):
Code: [Select]
;---------------------------------------------------------------------------;
; ADC_Task: Measure ADC output at periodic intervals                        ;
;---------------------------------------------------------------------------;

 IF (ADCStateTableEnd > 0FF)
  ERROR "Jump table out of 8-bit page 0 in ADC_Task"
 ENDIF
 IF ((ADCStateTableStart - 1) & 0FF00) != ((ADCStateTableEnd - 1) & 0FF00)
ERROR "Jump table crosses page boundary in ADC_Task"
 ENDIF
 
ADC_Task movf ADC_task_state,w ; Get state (0 to 4)
addwf PCL,f ; vectored goto based on current state
ADCStateTableStart
goto ADC_wait ; 0 (waiting for timeout)
goto CAL_ADC ; 1 (start ADC calibration cycle)
goto CONV_ADC ; 2 (start ADC conversion cycle)
goto WaitForDRDY1 ; 3 (take CONV low when DRDY goes low)
goto WaitForDRDY2 ; 4 (take CONV low when DRDY goes low)
ADCStateTableEnd
This also checks if the jump table is not in page 0. If it is not in page 0, PCLATH needs to be set correctly before the addwf PCL,f instruction. Your initialisation code must set PCLATH correctly, and it needs to be saved and restored by the interrupt handler. neglecting to do this may explain why your code works after a programming operation, but not a reset.
 

Offline katzohkiTopic starter

  • Frequent Contributor
  • **
  • Posts: 378
  • Country: us
    • My Blog
Re: PIC - getting lost / stuck in data table
« Reply #34 on: February 10, 2015, 05:24:25 pm »
OK, now that is something I didn't think of. I was "trusting" jump and PCLATH to be 0x00 on boot-up, but you have a good point. I will add statements to clear any variables during initialization.

Now I think there may actually be a problem with my PicKit 3. It is no longer able to recognize or program the PIC. I tried with 3 brand new 10F322 in a breadboard with no circuitry connected to the PicKit 3 and it does not recognize their device ID. The program still runs on the 12F1840 so I don't think there is a problem with the PIC itself (still in the sort-of-working mode).

There was an over-current detected on one of the USB ports (the one my USB drive was plugged in). Also "someone" a few weeks ago got drunk and wired in a negative 5 Volt regulator that may have caused damage to the PicKit and / or USB ports. So what do you guys think? Do I need a new programmer? Is there a way to test it? Mplab X says self test is not supported.
 

Offline 22swg

  • Frequent Contributor
  • **
  • Posts: 274
  • Country: gb
Re: PIC - getting lost / stuck in data table
« Reply #35 on: February 10, 2015, 10:26:35 pm »
katzohki   PK3  is fairly robust... changing PIC numbers...  the PK3  will have to reload FW / AP one or both  from IDE , has it done this ? what LEDs twinkle   ....

MPLAB X will report status if you click refresh debug tool status...  green arrows on navigator side bar... also it will load the FW if PIC part is connected and powered....

I picked up my asm "skills"  from magazine articles they always cleared ram and set pages on reset, so I always included a sub to do that.

At this level I think a structured code layout is required, like the previous post by Voja . also try to develop code  in small steps .

Hope I haven't been teaching my Gran to suck eggs !

If you post here with a PK3 topic I am sure you will get lots of good suggestions ....
Check your tongue, your belly and your lust. Better to enjoy someone else’s madness.
 

Offline katzohkiTopic starter

  • Frequent Contributor
  • **
  • Posts: 378
  • Country: us
    • My Blog
Re: PIC - getting lost / stuck in data table
« Reply #36 on: February 10, 2015, 11:29:07 pm »
OK so here's the deal.

Number 1: The application works now (yay!  :-+ ) Thank you all for the great help. I think between putting the table at the top of code and clearing my variables at initialization fixed it.

Number 2: The PICkit 3 did indeed have a problem. Fortunately, it was a software issue and not a hardware one. I had to use the PICkit 3 scripting tool to reload the PICkit 3 operating system onto the PK3. Whatever happened, it must have corrupted the PK 3 somewhat. Once doing that, I was able to use the scripting tool to erase, verify and load hex files into the PICs again. Then I had to reset configurations in MPLab X and now everything is working as it should.

I was getting pretty frustrated Friday night, we were having a windstorm. All day people were coming and going and my desk looked like a disaster area, my fence gate got torn off and sections of the fence got knocked down. And to top it all off we finally lost power for several hours. I'm guessing that one of the brownouts or power surges might have something to do with the PK3 getting corrupted. I did have that mysterious overcurrent warning on the USB hub too.

Again, thank you for all the help. I really do appreciate it and I was really trying all the suggestions, but I think at a certain point the hex file wasn't getting written properly anymore. Oh, and by the way, don't drink and engineer!  :palm: Or else you might place a negative 5V regulator instead of a positive one!
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: PIC - getting lost / stuck in data table
« Reply #37 on: February 11, 2015, 02:51:34 am »
Quote
Whatever happened

It usually happens if you power on the board before the pickit3 (or 2).

Reloading the OS solves quickly.
================================
https://dannyelectronics.wordpress.com/
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf