Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Found Unknown Device [solved]
#1
Hi,
I'm updating bootloader firmware using your latest builds and have run into the following problem.
Device = pic24hj64gp506 using UART2 at 19200 (also tried 9600)

When I connect I get the message
Found unknown device id(118)fw ver 4.0.0

The device ID should be 54 (Note in binary, it is only 1 bit difference from 118)
Now if I enable .equiv USE_ABAUD (and adjust the client side to use auto baud), it connects: but I can't use that option as there are already lots of devices in the field with the old bootloader that does not autobaud.

Any idea what might cause this problem?
Thanks
Reply
#2
Which versions/package did you use before?
Do you use the same clock settings?
Have you read the errata?
Reply
#3
(2011-04-18, 19:32:28)Mikael Gustafsson Wrote: Which versions/package did you use before?
Do you use the same clock settings?
Have you read the errata?

The problem was caused by not exporting the hex file.
For the help of others. The .hex file created when you compile does not have the device configuration settings embedded. Thus if you attempt to use it with PK2CMD no device settings will be programmed.
In my case, I have an external 8MHz xtal, and because the configs were not set, the internal osc (also 8MHz) was enabled, but its baud rate was 17.1k (instead of 19.2) producing subtle com errors.
Reply
#4
Which language tool set and IDE do you use?
The configuration settings are usually included when you use Microchips products.
Reply
#5
(2011-04-19, 20:57:43)Mikael Gustafsson Wrote: Which language tool set and IDE do you use?
The configuration settings are usually included when you use Microchips products.

MPLAB 8.46
After more investigation, I have found the config bits ARE included in both a standard build and an export. (note they are at 0x1F00000 if you use a hex editor)
I also think the problem may have been with the IDE switching the 'Configuration Bits set in code' check box off when reopening the project. I have now defined all the config bits in code to hopefully prevent this happening again.

*NEW INFO*
I now know why I think the settings were not sticking.
In windows 7, any files written to a programs executable directory are redirected to a 'compatability' folder in the users directory. Thus there are two copies of your file. The original in the c:\Program Files\... and a copy of your changed file in a 'compatability' folder. When you re-read the file, it reads the unchanged file not the one from the compatability folder.

Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)