I have this PIC, and since you seem to be familiar with it, maybe you know the answer. When I program the PIC, I find that the code is only executed from about location decimal 60 decimal. That is everything before that location is ignored. The PIC jumps directly to org D'60'.
Now there could be problems everywhere, but consider this code:
org 0 goto start
org 0x8 retfie
org 0x18 retfie
start: flip LED routine goto start
Nothing happens.
But this works:
org 0 goto start
org 0x8 retfie
org 0x18 retfie
org D'60' (any lower address no go). start: flip LED routine goto start
and that works! It does not hang in the reset loop! it skips over it! Lower then 60 for org does not work at all....
Only thing I can think of is that the PIC somehow enters debugging mode. I have read about a debugging flag. However in the related documents no debugging flag or related register is to be found. I have tried 2 PICs and both do exactly the same.
I checked the generated code, and listed it from 2 different programmers, and also assembled it with 2 different assemblers one MPASM, the other gpasm, exactly the same result. The fact that the PIC skips the interrupt vector space makes it totally useless for me. Any ideas?
All other code (no interrupts) executes normally after org D'60' or higher...
I tried making a project with that PIC but I found MPLAB SIM is not available for it. However it is available for 18F14K50 and it assembled and ran OK, with the start loop at memory location 0x1A. I set the processor to
18F14K22 and reassembled. The disassembly listing still showed the loop at
0x1a. Same if I use Debug mode. I'm using MPLAB8.15a.
Perhaps you should check your disassembly listing. And I assume you are only using the MPASM and not a C compiler which adds start-up code?
I'm not familiar with that model PIC, but I checked the linker script files and found one that might cause such problems. I've never seen one quite like this. And the use of #FI for #ENDIF is a new one on me.
Paul
// File: 18f14k22_g.lkr // Generic linker script for the PIC18F14K22 processor
Unfortunately, there are many more ways that things can go wrong than right. I've never seen this problem. But then I'm using vanilla MPLAB runing under XP, Win2K or Win7 64, plus ICD2, ICD3, PicKit2, PicStart, PicKit3 or RealICE.
location decimal 60 decimal.
Try using MPSIM and see what happens when you look at the program memory and when you step into the program from a simulated /MCLR reset.
ISRL ORG 0x0018 ; Run the High Priority Interrupt Service Routine GOTO LOW_ISR
;------------------------------------------------------------------------------ ; MAIN PROGRAM ;------------------------------------------------------------------------------
START
; dummy program that loops forever
GOTO $
In this case, the value of START is 0x1C (28d), which is right after the 4-byte LOW_ISR vector (GOTO 0x36 in this case, located at 0x18-0x1B.
found.
Well, when you use MPLAB the debug configuration bit is controlled "behind the scenes" by the selection of release vs. debug drop-down window (also there is a debug executive that is loaded into high program memory in debug mode). Microchip has taken to hiding this bit from unwashed data sheet users-- it's shown as "unimplemented" and "reads as zero". If you're using your own programming software you need to control it explicitly.. in this case it's bit 7 of CONFIG4L located at 300006h. Set it to '1' to disable background debug (and I also suggest disabling LVP).
for me.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
On a sunny day (Fri, 05 Feb 2010 05:19:57 -0500) it happened Spehro Pefhany wrote in :
I wrote: Wow! good data, now that is what I was looking for. I will try this, and of course also run your example, later tonight:-) Many thanks!
OK, I have tried it and it works now 100% OK, with rather complicated code too.
A few suggestions to Microchip:
1) That debug bit is by default enabled it seems, as the assembler (gpasm) generates a 0 for that bit. Debug is not a normal processor mode, and not even a wanted mode by many, so by default it should just behave normally. 2) As you address a rather large market, and millions are using other operating systems and other programmers, the debug bit MUST be documented. Otherwise you end up with a lot of frustrated programmers, who then turn away from the PIC for 'something that works'.
I personally think the debug bit is not a feature but a bug! A car that keeps the doors closed when you want to get in, is a just not a smart idea. If this is an attempt to sell more of your own programmers, it is a very very bad idea.
So for the public interest, here for the PIC 18F14K22 the real config space:
This example I used the internal oscillator, and disabled the MCLRE reset.
CONFIG FOSC = IRCCLKOUT ; Internal RC oscillator, CLKOUT function on OSC2 CONFIG MCLRE = OFF ; RA3 input pin enabled CONFIG MCLR disabled
From gpasm assembler HEX file: :02 0000 04 0030 CA Extended Intel hex record, upper bytes new base address
300006h CONFIG4L !DEBUG XINST -- -- BBSIZ LVP -- STVREN -0-- 01-1 05 ***** bit 7 CONFIG4L 300006h must be 1 to disable debug. ****
300007h ff
300008h CONFIG5L -- -- -- -- --
-- CP1 CP0 ---- --11 03
300009h CONFIG5H CPD CPB -- -- --
-- -- -- 11-- ---- c0
30000Ah CONFIG6L -- -- -- -- --
-- WRT1 WRT0 ---- --11 03
30000Bh CONFIG6H WRTD WRTB WRTC -- --
-- -- -- 111- ---- e0
30000Ch CONFIG7L -- -- -- -- --
-- EBTR1 EBTR0 ---- --11 03
30000Dh CONFIG7H -- EBTRB -- -- --
-- -- -- -1-- ---- 40
Legend: x = unknown, u = unchanged, = unimplemented, q = value depends on condition.
May google find this for all who also try to write a PIC 18F14K22 programmer. No idea if it is the same for other PIC 18F types.
A final remark: I think low voltage programming is a bad idea, as it sacrifices an other pin on a 20 pin package. Always short of I/O, and MCLRE is already restricted to input only, and there are restrictions on program data and program clock inputs too. Also I do not see how you can guarantee that the application circuit will never accidently enter a programming sequence.
FYI, I submitted the following on the Microchip Forum and I also submitted a defect ticket:
There was a recent discussion in the newsgroup sci.electronics.design about a problem with programming the PIC18F14k22, and it was determined that the DEBUG bit in the CONFIG4L register had to be set to 1 to disable the debugger. In the documentation for this and the PIC18F14k50, this bit is reported as unused and read as a zero. However, this IS the DEBUG bit and it must be specifically set to 1 in order to program and use the part properly. It may be that MPLAB and the usual programmer hardware takes care of this automatically, but it is a problem for third party and homebrew programmers.
It is especially strange that the bit is preset to zero, while in other parts, such as the PIC18F2420, it is preset to 1, and the documentation clearly specifies it as the DEBUG bit. The literature for the PIC18F14kxx refer to the DEBUG bit in the section on the debugger, but the identification of the bit in the CONFIG4L register has been removed and replaced with the incorrect information.
I'm not using these parts, and I use Microchip ICD2 and MPLAB, so it might not be a problem for me if I do.
One other oddity is that the MPLAB 8.15a SIM does not support the k22 part but it does work for the k50 part. Maybe it's been added to a newer release. I think these are fairly new parts.
On a sunny day (Fri, 5 Feb 2010 17:10:12 -0500) it happened "Paul E. Schoen" wrote in :
Thank you, good they know about it. I am not sure what the bit value is by default, but I do see that the assembler writes a zero there. So I added a line of code to my programmer that overrules any input, and sets that bit to one (or leaves it at one). Chip works great now, have the internal clock at 16 MHz and 4 x PLL enabled for
64 MHz, seems to work. Just playing around with it. Wrote some macros to port the old 16F690 instructions...
I got a response from Microchip and they glossed over my questions about the erroneous documentation and the possible wrong default bit setting in the silicon, and instead told me that the new version of MPLAB does support this device. Shame on me for confusing them. Probably ADD so they only remembered the last paragraph. I left a comment and maybe I will hear a response, but they marked the issue as "resolved". But not closed...
There is another thread about this device and apparently there is a problem in the MSSP module:
Don't stop there. I've taken the time to carefully box things into a corner with them where there was no possible escape except either a "No, we won't answer that." or else a "Yes, and here is where to go." It was somewhat painful, because they were seemingly getting adept at evading things. But the way to do it was to not write a reply to them that addressed _anything else_ but the point I wanted to have an answer on. If you include _any_ other topic or sentence in your response, they will latch onto that part and "appear" to somehow miss the main point.
Stay on target. Nail them.
What happened may be that you left them a 'last paragraph' to focus on, while ignoring the rest. Try another shot, only this time make sure there is only ONE thing to respond to. Don't even include "the weather here is nice" because that may be what they latch onto, if you do.
Hopefully, a __narrowly__ worded response. Thanks for pressing. I'd like to hear the results, too!
I'm sure he is, too. Spehro may have saved him a lot of wrangling.
On a sunny day (Mon, 8 Feb 2010 17:53:35 -0500) it happened "Paul E. Schoen" wrote in :
No, not your fault, Microchip should release complete specs. That will make life easier for programmers like those who write gpasm, as then the debug bit can just be a CONFIG option for this chip, so it should be in P18F14K22.INC. It should *not* be something that the programmer software does.
Anyways, I do not use debug, never do, last time was in the eighties with CP/M. Usually when people grab to debug it means they have no oversight of what they are doing. How do you think I concluded it was the debug feature that was the problem? Using debug? Come on guys, learn to program! And that means analysis, most cases what is the problem has already showing all symptoms clearly in front of your nose. Two things you need to have: 1) A clear mind, and 2) know about successive approximation. So that was a little bit of philosophy :-)
My experience with 'help desks' of any company is very very bad. Latest was with Vodafone, I asked them where the transmitter mast for my GSM phone was, (so I could erect an external antenna to get better reception for GPRGS modem at home), and they simply ignored the question... and gave some stupid answer about that if enough complaints came in they would move the beam a bit (perhaps). Now Vodafone is not doing very well, can you imagine why, I will be out of there as soon as anything better manifests.
I have ported a rather complicated program from 16F690 to 18F14K22, and needed quite a few modifications. as register have beend added, flags have been moved to other registers, the instruction set has changed, other things have changed, but i got it all working including WDT, BOR, and interrupts, but have not tried MSSP SPI yet, as I do not need it. But it likely is some user config problem. Reading datasheets, at times I go over it again, and try out all those cool hardware peripherals. It really is a very nice chip.
I may publish that asm that later, on the io_pic page. The asm file is >3900 lines, but I included a lot of docs into it. Memory about half full Program 7500 bytes at address 0x000000 ID 0 bytes at address 0x200000 Config 14 bytes at address 0x300000 EEPROM 0 bytes at address 0xf00000 I think the programmer software is now pretty much finished, only thing to add would be more 18F PIC types. And that at version 0.2!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.