Programmer connected or not connected - SOLVED

[bcfd36]

I am using an 18lf45K22 with a ICD-U64 programmer. Compiler version 5.018.

I am working on inherited code. I don't think the section I am looking at was ever tested. There is a comment in the code that says that if input(PGD) is low, the programmer is connected. The code itself is:

if(!(input(PGD))

PGD is defined as PIN_B7. The comment and code seem to be wrong. But here is where things get strange.

I have looked at 6 different modes of program/startup with the following results:
1. Debug build, programmer attached to card, fresh load, run - pgc 0, pgd 1
2. Debug build, programmer attached, power cycle, run - pgc 0, pgd, 0
3. Debug build, programmer not attached, power cycle - didn't seem to run
4. Non-debug build, programmer attached, run from Device Programmer window - pgc 0, pgd 0
5. Non-debug build, programmer NOT attached, power cycle - pgc 0, pgd 0
6. Non-debug build, programmer attached, power cycle, run from DP window - pgc 0, pgd 0

So here is the question, how can I start the program in non-debug mode and tell if the programmer is attached or not? I have been looking at the literature, but haven't found anything yet.

What I really want to do is the following:

[drolleman]

Biggest question why?

I think you found out that there is no info for this. The programmer is a master device and won't be listening for communication from the pic. So are you looking to check if the memory has an error? If so why are you needing to know if a programmer is attached? You will have to also check for all Microchip and third party programmers / debuggers.

David

[bcfd36]

Why? Well, because I was told to do so. But it makes sense.

We need to absolutely positively ensure that the program that is stored is what was there originally and nothing has changed. The best way to do that is to calculate a CRC for eeprom memory (well, most of eeprom memory) and then store that value in eeprom memory. You do this when the program is burned into eeprom, which means the programmer is attached. Later when the program restarted with the programmer NOT attached, you compute the CRC and compare it against the stored CRC. If they don't match, there is a problem and then use of the device comes to a grinding halt.

Also, various initial calibration data needs to be stored, only the first time the program is run. Which would be when the programmer is attached.

And no, only one type of programmer will be used. I just need to know if it is there or not. Which is the question I initially asked.

Again, is there a way to tell if the programmer is attached or not?
PGD low does not seem to be it. But I could be wrong.
D. Scruggs
_________________
D. Scruggs

[Ttelmah]

Basic answer. No.

You could however design the programmer connection so you can.

Basically the programmer when in use operates the PGC line. However as soon as this is done, the chip stops running. So cannot be used to detect the programmer.
The PGD line the programmer operates or does not operate according to debug mode, so this cannot be used to detect the programmer.
However you could have something like a flap over the programmer connector with a micro switch and detect if this is open/closed.

That having been said, why not just include the CRC with the code?.
Then your code can verify that the CRC in the EEPROM matches the CRC of the code, to know if anything has been changed. The compiler has the ability to calculate the CRC and write it to the chip ID locations (#ID checksum). You can just have your code on first boot, copy this to another location in EEPROM, and then on subsequent boots, verify that this other copy, and the ID copy both match the checksum of the code. Any difference implies the code has been changed....

You can tell 'first boot', by having a code number stored in the EEPROM locations like 0xAA55. If this is there, then this is an initial boot. Then overwrite this with the CRC.

From what you are describing on 'initial calibration', this could simply be triggered by identifying the same 0xAA55 marker.

[RF_Developer]

Another thing to consider is that code checksums and CRCs are used to compare what should be with what is. Its not a lot of use having the code generate its own checksum/CRC: its too late, it could already be corrupt - it doesnt "absolutely positively ensure that the program that is stored is what was there originally and nothing has changed." So, its normal, indeed almost universal in my experience, to get some external tool compute the checksum/CRC and add it to the code before it is programmed into the PIC. Generally, that's done by the compiler/IDE. This process is tried and tested. Getting the PIC to compute its own checksum/CRC at first run is not.

I use code checksumming in many of my projects. If its any consolation, so far, I have never seen any bonafide checksum failure on running systems. Also, I suspect that in many cases that if the PIC were to be sufficiently damaged to change the code, then it wouldn't run at all.

I use the #ID checksum method of getting the compiler to compute the checksum for me. I have tried to include the rather better (at detecting errors) CRC, but few, if anyone, seemingly has ever managed to work out exactly how CCS compute the CRC, and therefore cannot reproduce it at runtime.

You need to differentiate between the "programmer" and "debugger", even though the same hardware is being used. Its straightforward to determine if the code is being debugged. Debugging requires firmware support, and the fuses are necessarily changed. Debug code is NOT the same as release code, and the checksums/CRCs for the two versions are different.

You have seen by experiment that there is no hardware method of detecting if ICSP hardware is connected, after all, its just a bit of hardware plugged in. Unless some specific means had been provided to identify it, then the chance of being able to do so is slim.

Many of my systems do not, normally, run with the programmer connected. We often program using power from the programmer (we ue Load-N-Gos) and there is no guarantee that the unit is powered up and running for any length of time after the programming cycle has been connected.

Further, you report that this code feature is not been tested, or made to work. There probably was a good reason for that. The basic approach being flawed (the assumption that it would be possible to detect when the PIC was running with the programmer connected...) could well be part, or all of that reason. You have now proved that the comment "...that says that if input(PGD) is low, the programmer is connected" is just plain wrong.

[newguy]

[bcfd36]

Well Boys and [spam], I found out more about what was going on...

It turns out you CAN tell if the programmer is there on this particular chip. The problem was with a call to port_b_pullups(TRUE). It didn't quite do what we thought it did. On other chips, this call would pull all the port B pullups to high. But on my particular chip, 18LF45K22, it didn't quite work this way. Apparently, from what I was told, you had to tell each line in port B what it would be. So when I changed the call to port_b_pullups(0xFF), things started working like we expected. With the programmer in place, PGC and PGD were both 0 (the programmer pulls the pins low) and with the programmer detached, the pins were both high.

Thanks for your input. And, yes, I probably should have posted all the code, but for reasons I won't go into, it wasn't practical.

D. Scruggs
_________________
D. Scruggs