Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About chuckk

  • Rank
  1. Thanks for the suggestions. I did a lot of thinking over the weekend on this. This is for a test set for production. There's an ICD port on the tester, so reprogram is easy. There are no PCs readily available where the tester will be used, and once the code is verified OK by our customer, the 10F code will never change. The 16F part is the tester; the 10F part is the target. I am using a bootloader in an 18F project I designed - that one is intended to allow remote reprogramming via modem, and it works nicely. I do use the WDT. I've seen too many PIC projects "lock up" due to noise over the years where this was not done. I've pretty much decided to write a translator to take the Intel HEX file and convert it into a bunch of "#pragma DATA" statements, then just do a "#include hexfile.hex" to make it part of the 16F code. We are going to be doing many more ICP projects down the road, so it makes sense to build an infrastructure to support this. Chuck
  2. I want to put the program code for a PIC10F200 into the ROM of a PIC16F876, so that a fixture I am building can do in-circuit programming of the smaller processor. I know I could put the PIC10F200 code into ROM using "#pragma DATA", but I don't relish the thought of typing in up to 512 bytes of program code - just think of the grief if the code changes. I've seen programmers that use a PIC to program other PICs, but these mostly work with serial input data, not stored data. I really want to make this a one-chip solution if possible. I was thinking along the lines of doing a #include "hexfile.bin", where the binary image of my program is already in the proper format, but don't see how to make the compiler accept this. Perhaps there's a way to link in a hex file at a fixed address - but again, I don't see how. Any advice would be appreciated.
  3. It was the system library. I will have to figure out why SourceBoost is using the old one, while MPLAB finds the new one OK. Chuck
  4. Hello, I recently upgraded to V6.55. All seemed well when I ran the compiler and linker through MPLAB, but when I attempted to build a library file in SourceBoost, I get this: Building... BoostLink Optimizing Linker Version 6.55 http://www.sourceboost.com Copyright(C) 2004-2006 Pavel Baranov Copyright(C) 2004-2006 David Hobday Error: .obj or .lib file Incompatible version! (file uses V106, linker requires V107) Error: Failed to process:libc.pic18.lib Failure "C:\Program Files\SourceBoost\boostlink.pic.exe" /ld "C:\Program Files\SourceBoost\lib" libc.pic18.lib relay.obj "Relay Library.lib" /t PIC18F4620 /d "D:\SW work\Mid State\Relay Control" /p "Relay Control" -rb 0x4000 Exit code was -2. Removing target: Relay Control.hex Failed to locate output file 'D:\SW work\Mid State\Relay Control\Relay Control.hex' Done Failed When I build the project in MPLAB, I compile the library file along with the main C file, so this problem does not arise. I can redo the SourceBoost project to compile both files rather than use the library, so this is not a show stopper, but I thought you should know about it. Regards, Chuck
  5. [ <{POST_SNAPBACK}> Upgrade to BoostC V6.55.This will allow a function to be called from more than thread of execution and gives a serious warning. Unless you ensure that the calls from the two thread cannot occure at the same time (re-enterancy) then the software stack will become corrupted. You can prevent the function from being called from the interrupt routine when called from the main thread of execution by disabling interrupts before the call. This code won't suffer from software stack corruption problems: void foo() { ... do something } void interrupt() { foo(); } void main() { Disable Interrupts foo(); Enable Interrupts } Regards Dave <{POST_SNAPBACK}> Thanks. I will do that. Anyway, I found a workaround for this case, after tracking down where the offending function was getting called from - instead of a divide, I use a right shift - no more problem. Chuck
  6. Hi, I have a block of code that needs to be called from a periodic interrupt. The code compiles OK, but in the link I get this: Error: Function called in more than one execution thread: __div_16_16 This is running on a PIC18F4260. Is there any way to either get source to this function or to force a call to an interrupt-friendly version? Thanks!
  7. What you have done here is to put the pointer to the rom string at a fixed address. You can't specify the placement of a rom string at a fixed address. The best way todo this is to place your data in high memory using the #pragma DATA directive. You will then need to write a routine to read it. Regards Dave <{POST_SNAPBACK}> I was afraid of that... Thanks Chuck
  8. Hi, I am trying to locate some ROM data in flash program memory. This data would be modified by the program during start-up of the product, and then read by the program during power-up thereafter. I declared some strings: rom char* rom_serial@0xc040 = "00000"; rom char* rom_delivery@0xc046 = "01/01/2001"; rom char* rom_customer@0xc052 = "Mid State Engineers, LLC"; The assembly output shows the following assignments: gbl_rom_serial EQU 0x0000C040; bytes:1 gbl_rom_delivery EQU 0x0000C046; bytes:1 gbl_rom_customer EQU 0x0000C052; bytes:1 as I would expect. Startup code does this: MOVLW 0x00 MOVWF gbl_rom_serial MOVLW 0x01 MOVWF gbl_rom_delivery MOVLW 0x02 MOVWF gbl_rom_customer which makes no sense to me - why are ROM constants being trated like RAM? The string data, however, gets put at a random location. From MPLAB disassembly: 52: rom char* rom_serial@0xc040 = "00000"; 23EC 0E00 MOVLW 0 23EE 6E40 MOVWF 0x40, ACCESS 53: rom char* rom_delivery@0xc046 = "01/01/2001"; 23F0 0E01 MOVLW 0x1 23F2 6E46 MOVWF 0x46, ACCESS 54: rom char* rom_customer@0xc052 = "Mid State Engineers, LLC"; 23F4 0E02 MOVLW 0x2 23F6 6E52 MOVWF 0x52, ACCESS Again, it's doing something with RAM, but no string data appears. When I access these strings, they print out properly, but there's nothing at the ROM locations above 0xC000. What is happening here? Is it possible to force a ROM location like this, or am I just confusing the compiler?
  9. I've found the problem. The TBLPTR register must be within the range of the page being written. My code did a postincrement on the tblwt opcode; this left the pointer one byte past the page I wanted to write to. Onward...
  10. I have set eecon1.EEPGD = 1 and eecon1.CFGS = 0 before all accesses. I am also using the data EEPROM on the chip, and am having no problems at all with access there, either read or write. I made sure there's plenty of bypass capacitor present right at the processor's power pins, and the power supply is regulated via a 7805 close to the part. I don't see any noise at the power pins that could interrupt programming - but reads should not be so critical, I hope.
  11. The returns appear at different points in the code, but are lumped together when you look at the code window because they are associated with the same source code line. Have a look in the .asm or .lst file. Regards Dave <{POST_SNAPBACK}> Thanks. I knew there was a reasonable expalnation Chuck
  12. Hi, I am trying to get a bootloader running on an 18F4620. According to the Microchip data sheet, I am doing everything right to be able to read flash program memory. The assembler output from BoostC looks just like the code example given in the data sheet for doing a read. Unfortunately, it does not work. I have put 0xff55 in flash memory at location 0x7ffe using a #pragma DATA 0x7ffe, 0x55 statement - can see it in the program memory screen in MPLAB - but when I attempt a read of location ox7fff, I get a return of 0xff instead of 0x55. Attempting to read 0x7ffe returns 0xff also. Has anyone successfully used flash program reads and writes on one of these chips?
  13. In looking through the assembler output from SourceBoost, I have noticed that several functions end with repeated "return" opcodes. In one case, i saw three consecutive returns. Is there a reason for this? Seems like wasted bytes. Here's a snip of disassembly: 855: 856: if(tx_head >= TX_BUFFER_SIZE) // Reset pointer at end of buffer 0086 0E01 MOVLW 0x1 0088 5C50 SUBWF 0x50, W, ACCESS 008A E104 BNZ 0x94 008C 0E00 MOVLW 0 008E 604F CPFSLT 0x4f, ACCESS 0090 D001 BRA 0x94 0094 A0D8 BTFSS 0xfd8, 0, ACCESS 857: { 858: tx_head = 0; 0098 6A4F CLRF 0x4f, ACCESS 009A 6A50 CLRF 0x50, ACCESS 859: } 860: } 0092 0012 RETURN 0 0096 0012 RETURN 0 009C 0012 RETURN 0
  14. I don't see why it should not work, so your are taking the .asm output from BoostC and combining it with another .asm file?Remember to use the -rb 0x400 linker command line option to offset the code If you get this to work, you will of course be debugging in assmebly language rather than C source code. Regards Dave <{POST_SNAPBACK}> Both asm files are from BoostC. Either one alone links up fine. Together, I get the error. The file org'ed at 0x4000 is truly there, according to the asm output from BoostC. I tried removing all the org statements from the file to be placed at 0x4000, and got the same error message. Something in MPLAB linker? Chuck
  15. Hi, I am attempting to link two files generated by BoostC using MPLAB. The code compiles correctly and at the proper addresses - I am compiling and linking using BoostC IDE, then attempting the link the ASM files in MPLAB so I can use my ICD2 to debug. The two files are a "bootloader" which resides at 0x0000, and an application which resides at 0x4000. The assembly output files from BoostC look correct, but when I try assembling and linking in MPLAB, I get a linker error: (warnings are referencing the configuration words) Executing: "C:\Program Files\Microchip\MPASM Suite\MPASMWIN.exe" /q /p18F4620 "Relay Control Boot.asm" /l"Relay Control Boot.lst" /e"Relay Control Boot.err" /o"Relay Control Boot.o" Warning[220] D:\SW WORK\MID STATE\RELAY CONTROL\BOOTLOADER\RELAY CONTROL BOOT.ASM 1109 : Address exceeds maximum range for this processor. Warning[220] D:\SW WORK\MID STATE\RELAY CONTROL\BOOTLOADER\RELAY CONTROL BOOT.ASM 1110 : Address exceeds maximum range for this processor. Warning[220] D:\SW WORK\MID STATE\RELAY CONTROL\BOOTLOADER\RELAY CONTROL BOOT.ASM 1112 : Address exceeds maximum range for this processor. Warning[220] D:\SW WORK\MID STATE\RELAY CONTROL\BOOTLOADER\RELAY CONTROL BOOT.ASM 1113 : Address exceeds maximum range for this processor. Warning[220] D:\SW WORK\MID STATE\RELAY CONTROL\BOOTLOADER\RELAY CONTROL BOOT.ASM 1115 : Address exceeds maximum range for this processor. Warning[220] D:\SW WORK\MID STATE\RELAY CONTROL\BOOTLOADER\RELAY CONTROL BOOT.ASM 1116 : Address exceeds maximum range for this processor. Warning[220] D:\SW WORK\MID STATE\RELAY CONTROL\BOOTLOADER\RELAY CONTROL BOOT.ASM 1117 : Address exceeds maximum range for this processor. Executing: "C:\Program Files\Microchip\MPASM Suite\MPASMWIN.exe" /q /p18F4620 "Relay Control.asm" /l"Relay Control.lst" /e"Relay Control.err" /o"Relay Control.o" Executing: "C:\Program Files\Microchip\MPASM Suite\mplink.exe" "D:\Program Files\Microchip\MPASM Suite\LKR\18f4620i.lkr" "D:\SW work\Mid State\Relay Control\Bootloader\Relay Control Boot.o" "D:\SW work\Mid State\Relay Control\Relay Control.o" /o"linkboot.cof" /M"linkboot.map" MPLINK 4.03, Linker Copyright © 2006 Microchip Technology Inc. Error - section '.org_0' type is non-overlay and absolute but occurs in more than one input file. Errors : 1 BUILD FAILED: Wed Sep 27 15:03:03 2006 I cannot find any references anywhere in the generated assembly code to "section '.org_0'" - and Microchip's linker help pages are not very helpful. Any ideas?
  • Create New...