Activity for Tiny Multi Bootloader+
-
Anobium posted a comment on discussion Requests
Hi David. Evan here. Ping me a personal email and I can sort for you.
-
David Brooks posted a comment on discussion Requests
Hello, I'm looking for a bootloader for the PIC18LF27K40. Preferably the source code so I could make some changes to configuration. If at all possible, that would be great! Thanks!!
-
See attached for compilers supported.
-
Michael Groß-Bölting posted a comment on discussion General Discussion
I did not change the comments! It is only for dspic33ep16gs506!
-
I did not change the comments! It is only for dspic33ep16gs506!
-
; change these lines accordingly to your application .equ __dspic33ep16gs506, 1 .include "C:\Program Files\Microchip\xc16\v2.10\support\dsPIC33E\inc\p33ep16gs506.inc" ;.equ IdTypePIC, 0xA3 ; Please refer to the table below, must exists in "piccodes.ini" .equ IdTypePIC, 0x35 ;.equ max_flash, 0xAC00 ; 24FJ max address, not bytes!!! (= 'max flash memory' from "piccodes.ini" divided by 2), Please refer to the table below .equ max_flash, 0x2B7E ;.equ Fcy, 8000000/2 ; you may also want to change: _HS_OSC...
-
Any working Bootloader is a thing of beauty!!
-
Any working Bootloader is a thing of beaty!!
-
I only changed the firmware. This pics have different EEPROM commands! I can send you the firmware. But it is not beautiful!
-
Sure. I know the software and the firmware extremely well. What do mean by 'comments/structure'? the application or the firmware?
-
Thanks! My Firmware is running. But comments/structure is not so good. Can someone help me? No time in the moment.
-
Sure. I have uploaded to the existing Git. https://github.com/Anobium/TinyMultiBootLoader/tree/master
-
I need no change, i only want to have and understand it!
-
I will locate the source. Re the Windows EXE. What to change you need? we have another application suite for a specfic use cases, like 1. School usage where the only want to press 'load'. Chip type and hex are predetermined 2. Factory/manufacturing use where only the HEX is selectable 3. Encrpyting and decrypting the HEX in two applications to permit the sharing of the HEX but the end user cannot reverse engineer the HEX.
-
Ther is SW12.5 the actual is 14.6.5! Greetings Michael
-
Very much alive. See the CODE tab for the source.
-
Hello i created a firmware for: dspic33ep64(16)gs506 But is the TinyBootloader living? Where can i get the SourceCode from the 14.6.5 Greetings Michael
-
I have replaced the complexity of writing the bootloader with an application. The application essentially does this. Determines chip and the chip parameters from the GCBASIC reference/compiler files. Determines the parameters like freq, bps etc Determines TinyBootLoader+ chip ID. This is based on memory and HEF/SAF sizes, Determine the chip memory architecture and chip family. There are three difference chip family and six different memory architectures across all the PICs. Some of the memory architectures...
-
Waldo posted a comment on discussion Ask for Help
Hello, all! I´d like to create a bootloader for a PIC16F1829, but I have no clue how to do it. Is there a place where I have to download the firmware, or a software that I must use to configure the source code? Please, help me, I´m trying very hard to understand how Tiny Bootloader works!
-
Moi posted a comment on discussion Requests
Hi Really good job ! and thanks a lot for reply
-
See This shows the creation process and explains how it all works. Enjoy
-
@Moi. Send me a PM and I can have a go at the Q41 for you.
-
Hello I do not know if you can do that but if yes i like to get a bootloader for the pic 18F16Q41 If this is possible i like it 115200bds using RC5 as Rx and RC4 as TX. (also code read protection) Thanks, best regards
-
I just check my stock of chips. I do have the 45K50. I have otherK50s but none with five USART. Can you send me a chip ?
-
I have replaced the old ASM with an automated tool. The new chips are very different from the old chips and the new tool just works every time - there is no point in using the old ASMs. The new chip required the use of PIC-AS not MPASM and the new tool supports PIC-AS.
-
Avefenix586 modified a comment on discussion Tested Devices
Hello, I would like to suggest that you take into account these PICS from the list to generate their respective bootloader, these superficial PICs are used in the Curiosity Nano modules but they also have their "dual in line" DIP versions that can be used in breadboards or boards made . by yourself having your bootloaders available. EV53Z50A - PIC16F18076 (DIP40) EV72J15A - PIC16F17146 (DIP20) DM164144 - PIC16F18446 (DIP20) DM164148 - PIC16F15376 (DIP40) DM182029 - PIC18F47Q10 (DIP40) DM182028 -...
-
Hello, I would like to suggest that you take into account these PICS from the list to generate their respective bootloader, these superficial PICs are used in the Curiosity Nano modules but they also have their "dual in line" DIP versions that can be used in breadboards or boards made . by yourself having your bootloaders available. EV53Z50A - PIC16F18076 (DIP40) EV72J15A - PIC16F17146 (DIP20) DM164144 - PIC16F18446 (DIP20) DM164148 - PIC16F15376 (DIP40) DM182029 - PIC18F47Q10 (DIP40) DM182028 -...
-
Hello Anobium, thank you for your response, there I give you the Bootloader firmware for the PIC18F45K50 that I am testing, the Blink_45K50 program compiled in Mplab v8.91 to blink the 5 ports A,B,C,D,E at approximately 1 Hz . all the ports as digital outputs and the simulation file in Proteus 8.12, When I record the Hex of the led_blink_45k50 directly in the PIC with the Pickit 2 v2.62 Unofficial via ICSP this works well without problem put on a Board similar to those of "Penguin Pic" and in the...
-
I can try. Upload the bootloader hex and your test program hex and some documentation/schematic for the ports.
-
Hi Dan, I wanted to try the bootloader for the PIC18F45K50 and the Tinymultibootloader detected it but when I uploaded a flash program assembled in Mplab v8.92 to flash all the 5 ports it doesn't work, however when I program it directly to the PIC with Pickit2 Yes, the blink of the ports works very well, and if I program it again through the boot loader, the blink does not work, I have tried modifying the configurations but I have not been able to make the 5 ports A,B,C,D work As for digital outputs,...
-
ikonsgr74 posted a comment on discussion Requests
By "merge" i meant to have a single hex file that includes the bootloader code + any application code. Anyway, i sent you pm for the rest :-)
-
Thanks for asking. The Q10 is one of the chips supported by the new process, You cannot 'make' using GCBASIC as I am not planning to release. I will put on a new website where it should be possible to config and get a complete bootloader - this is a low priority in my backlog. Referri to merge. What do you mean ? What else do you want to add ? A bootloader is a small program that hands operations over to the user program. One of the principles is that the bootloader is less than 100 words ( this...
-
Hi, I would like to try the tiny multi bootloader+, so i need a bootloader HEX file. Is there any guide on how to create one myself? For example, can i make it using cowbasic, and also, can i "merge" the bootloader code with any existing code? The Tx, Rx pins i'm using are: RX2PPS = 0x0009 'RB1 > RX2 RB2PPS = 0x000B 'TX2 > RB2
-
Tiny Multi Bootloader+ updated /TinyMultiBootloaderPlusInstaller (v0.14.6.5).exe
-
-
-
-
Well done. The new code we developed does not call it CRCm you are spot on - it is a checksum. I have just completed a new development so TBL+ now supports all the new chips from Microchip including 18FxxQxx, 18FxxK83 and 18FxxK84 etc using PIC-AS. The video shows the result of a lot of development effort. .
-
BRIAN CLICK posted a comment on discussion Ask for Help
Sorted. The app sends a 2's complement checksum and the BL is using a simple rolling byte adder. The Release Notes for v14 (which I am NOT using) mentions something about a "crc" fix... v0.14.x (jan 2021) ------------------- PC Software: Added new config option to improve performance. Select Force block transfer to send data in blocks, not, byte by byte. Added EEPROM 18f write operations now support 18fxxq10,18fxxq41, 18fxxq43 Fix to CRC calculations <--THIS BTW it is a CHECKSUM being employed here,...
-
Evan Thanks for your reply. It's not a boot time issue, so the memory map concerns aren't a factor in the matter at hand. I've used TinyBL (the Claudiu build) on other projects since 2009 so I do understand how to set it all up and use it properly. The CONFIG block in the BL is lifted from my application code; this is not a concern. Yes I set PPS as required, same as in my application code, in which I employ the USART and that works fine. And Rx DOES work in the BL, as evidenced by the response to...
-
Evan Thanks for your reply. It's not a boot time issue, so the memory map concerns aren't a factor in the matter at hand. I've used TinyBL (the Claudiu build) on other projects since 2009 so I do understand how to set it all up and use it properly. The CONFIG block in the BL is lifted from my application code; this is not a concern. Yes I set PPS as required, same as in my application code, in which I employ the USART and that works fine. And Rx DOES work in the BL, as evidenced by the response to...
-
Set the PPS? If TX was wrong then RX wil be. We can produce a TBL+ for you. It costs £15. Send me PM for details. This is the report from the generator. TOOLVERSION .......... 1.06B IDTYPEPIC............ $A5 [PICCODES.INI] CHIP ................. 16F1614 / 14 PINS FREQUENCY ............ 32 Mhz OSCILLATOR SOURCE .... INTERNAL BAUD RATE ............ 19200 BPS PROGMEM WORDS ........ 4096 RAM BYTES ............ 512 CHIPFAMILY ........... 15 PPSCHIP .............. YES PPSCONFIGDEFINED ..... YES PPSTOOLPART...
-
Hi, I modified the original from Dan's FWUpdate_8 zip archive (Dan_tinybld16F1614-1615-1618-1619_int16MHz_19200_r1.asm) I used Device Type 0x27 (not 0x28) because the PIC16F16xx are HEF, not EEPROM At first, Check Device would fail. I then found the TXREG value was incorrect (line 203) retlw B'00010010' ;select TX for this processor, it needs to be retlw B'00000110' ;select TX After that change, some progress. Check Device is OK... Checking device Open COM12 serial port at 19200 Baud Rate Hardware...
-
Perfect. Well done. Great Job!!!!
-
Éimear Murphy posted a comment on discussion General Discussion
It was just the debug messages...working finally! Thank you for your help and patience, really really appreciate it. Re-posting the final .asm file to operate TMBL+ over RS485 on pic18f13k22. There was no changes made to piccodes.ini file. Main changes made to the .asm were for control of RC7 pin which enables transmit and receive to the pic. Some code was removed from the .asm file to allow the pin control changes to be made while keeping the code under 100 words.
-
Here is piccodes.ini, it is unmodified and allows the blink code to program successfully.
-
Note also I can get my real application hex code to program via the modified rs485 tbl when I change the piccodes.ini to have a greater max flash value, this and the debug messages that come up suggests to me that the PC software has an issue with the lenth of the real hex code application. However, as you previously pointed out, changing the value of the max flash in the piccodes.ini file messes up the jump vectors in the program memory.
-
Post you PICCODESINI Is this in error? Also, there is no way that the write will work if you have all the debug turned on and are looking at the debug tab. Thank you for your TBL. All looks good here... see attached.
-
No hex doesn't work. Message tab extended address: 0x0030 -> Configuration Bytes: :03000100681F1E57 0x0001: 68 1F 1E :02000500088170 0x0005: 08 81 :0600080003C003E0034009 0x0008: 03 C0 03 E0 03 40 minMemPos=00000000, maxMemPos=00001F40, blockSize=64 first 4 words at address 0x1F38: 0xEF06 0xF000 0xFFFF 0xFFFF Uploading PROGMEM Uploading program memory write mem pos: 0x00000000(byte) send: TBLPTRU=0x00, TBLPTRH=0x00, TBLPTRL=0x00, block=64 A0 EF 0F F0 FF FF FF FF 10 00 FF FF 0F EC 0F F0 93 9C 8A 8C...
-
Failure is with adapted code for rs485- but I'm able to program successfully the blink code for with adapted btl rs485. Attched is asm for reference.
-
I have just loaded this into a K22 using TBL developed here from our automated tooling. Source 99% of progmem used: Summary: Compiled: Program lines: 675 Subroutines: User: 0 ; System: 3 of 423 ; Total: 3 Chip resource usage: Program Memory: 4074/4096 words (99.46%) RAM: 0/256 bytes (0.%) OSC: IRC, 64Mhz (Internal oscillator) Assembling program using c:\microchip\mpasmx\mpasmx.exe Program assembled successfully (Assembly time: 1.218 seconds) Done TBL+ UI Messages window: Checking device Open COM2...
-
Checking by asking you. Is the failure with the adapted tbl code for rs485? or, stock tbl for rs232 ?
-
I will send you over the real hex via email. This is what I get in the messages tab when I try program the real application code User ID(s) removed from source extended address: 0x0030 -> Configuration Bytes: minMemPos=00000000, maxMemPos=00001F40, blockSize=64 first 4 words at address 0x1F38: 0xEF7C 0xF000 0xFFFF 0xFFFF Uploading PROGMEM Uploading program memory write mem pos: 0x00000000(byte) send: TBLPTRU=0x00, TBLPTRH=0x00, TBLPTRL=0x00, block=64 A0 EF 0F F0 FF FF FF FF 58 82 D9 CF 02 F0 DA CF...
-
Messages tab when loading blink code is as follows: Checking device Open COM8 serial port at 19200 Baud Rate Hardware RTS resetting device Device answer: 0x61 0x43='C' byte OK, now check ID-code and Family idCode = $61 family = C description = 18F w/8KB flash & 256B EE flash mem = 8192 bytes EEPROM mem = 256 bytes Bootloader size = 200 bytes Transfer block size = 64 bytes Device detected:18F w/8KB flash & 256B EE Closed COM8 serial port TinyMultiBootLoader+ device check completed Checking device...
-
Looking at the PDF tells me that the PC application and TBL are addressing each other correctly. And, this can be proven in the debug window - when the last block is transmitted.. this last block will contain the jump vector to the user program at location 0x0018. Please confirm the debug windows looks correct in terms of the last block. Assuming the last block (above) is transmitted correctly then we know the PC application and therefore PICCODES.INI is correct. So, when you upload you larger program...
-
Hi Anobium, Attached is the program memory without piccodes.ini and the the blink file loader via TBL. The memory is as you say above and I can see the pin toggling on the oscilliscope. There is no changes to piccodes.ini. However, when I try load my real application code, I get an Error on the TBL GUI. Simulating this on a virtual device tells me that my real application code hex file is too large. That is why I'm trying to changes picodes.ini (or make some change) so that my real application code...
-
The first PDF shows the initial reset jump vector 'GOTO 0x2F40' that is incorrect. Where is address 0x2F40 ? So, you know this is not correct as this should be 'GOTO 1F40' And, if the bootloader was working correctly then the jump vector as 0x1F38 would have the address of the user program. Which it does not. So, the INI file is incorrect. You need to have this working first. The initial reset jump vector needs to 0x1F40, and, the vector at 0x1F38 needs to correct after a load has happened.
-
So the blink code can be seen at the beginning of the program memory- addresses 0002 to 0086. But the pic will never get out of bootloader mode unless the first GOTO at address points to the bootloader at 1F38 (which it does when piccodes flash memory is set to 2000, but this won't work for my real application)
-
Where is the BLINK code loaded and operational in this bootloader ? I need that at dump.
-
File 2 attached, with bootloader with blink application code
-
Attached is file 1. The first file, is the program memory with just the bootloader code on it, just 1 GoTo at the beginning of the code and the rest of the bootloader software is at the end. The second is one with bootloader and after using the GUI to program the blink application code- since the real application code is larger I need to change the size of the flash memory in piccodes.ini. This updates the goto command at address 0000 which now points too far down the program memory.
-
Version is correct. Pull the PROGMEM and send it to me. I cannot visualise the layout of the memory.
-
The version I am using is 0.14.6.5 but I am not sure if this is the latest version. So without RS485 version it worked with small blink application, not real application. Real application involves using RS485 chip but since I had a FTDI RS232 cable wired to bipass this chip so could not test real application code, but I don't think this worked. Next I plan to edit piccodes.ini so that the bootloader appears to be much larger- so max flash memory will be larger and hopefully my configuration bits...
-
The version of the exe for PC - are you using the latest version? as this should resolve. But, I am confused. You said the baseline which has not RS485 support worked. Did it? Did you read the program in PICKit+ and look at the UI to see if the jump vector in the TBL was updated? If not, then this is really important to know. If it did set the jump vector in the baseline code then something else has gone wrong.
-
Yes but I think I am at an impasse. Editing this line in piccodes.ini allows the GUI to program the real application code- the GUI seems to not allow programming beyond half of the program memory. By going from a max flash of 2000 to 4000 we trick the GUI into programming beyond the half way point $61, C, 18F w/8KB flash & 256B EEPROM, $4000, $100, 200, 64, However, this means that the GOTO in memory points to a memory location that is not available on the Pic: Line Address Opcode Label DisAssy 1...
-
piccodes.ini as this informs the application.
-
Is it the piccodes.ini I change or the .asm? Presumably the piccodes.ini shows the PC software where to add the 'Go To' but I need to make sure I can use more than 50% of the program memory
-
I think you dont need to change.
-
It seems that only half the memory can be programmed. In order to upload the real application code to the PIC the piccodes.ini file had to be changed. Note the real application code when programmed directly reached line 2121 address 1090 which is over half the pic memory, which the gui would not allow when the line was $61, C, 18F w/8KB flash & 256B EE, $2000, $100, default, default, In order for the GUI to realise there was enough space, this had to be changed to $61, C, 18F w/8KB flash & 256B EE,...
-
Hi Anobium, Unfortunately I cannot share my hex file. However, I have gotten slightly further. I have managed to get my real application code /hex file programmed onto the pic via TMBL+. However the code still does not work. When I read the program memory back from the PIC I can see the full application code and the bootloader at the end of the program memory but the bootloader is missing the first 'GoTo' statement at the beginning of the bootloader code, so it gets stuck in bootloader mode and doesn't...
-
I want to load into PICKitPlus and look at the file.
-
Send me the asm and hex fo rTBL and your real application hex. Send me a PM to get my email address, if you do not want to post your real application hex
-
Hi, I reverted to the RS232 version of my asm code. I could check device and write the blink application code to the device. However, my real application code does not work in this instance too. Re-commenting the EEPROM code, and trying again. check device and the blink code programs, the real application code does not. I tried this also with RS485, again the blink program works and the real application code does not. Thanks
-
Questions: Did you test and get things to work with just the NO EE write operations? So, did you fully test that the removal of the NO EE write operations worked before you changed the the next step. So, no RS485 support and the same Write process. Did this all work ok? Then, did you test with just the changes to the Write process. So, building on the NO EE, just the change to call SendW ? Did this all work ok? No I dont what the issue is but confirm the two states above may help. PS This is why...
-
Hi Anobium, Thanks for your help. I tried your solution and it didn't work but I implemented a different solution and have had some success (see .asm attahced). The application code I posted above can be successfully write to the PIC via TBL. The application code above, to toggle a pin/ blink LED, was just a simple test program. My actual application code is a bit longer (having read back the program from my PIC on an ICD 4 the real application code finishes at address 1090 without bootloader code)....
-
You need to add four instruction - I believe. Set the port to an output bcf TRISC,7,ACCESS. Just beforeclrf ANSEL ; setup digital I/O Then, in RECEIVE add BCF LATC,7,ACCESS at the start, andBSF LATC,7,ACCESS twice ( befire the return and before WAY_TO_EXIT:). Agree > and this will fit within the 100 bytes.
-
RC7 is connected to the enable pin of the RS485 chip. It needs to go high when the Pic wants to transmit, and low in order for it to receive data from the GUI.
-
I dont think so. When does RC7 need to go high? and, when low?
-
Haha yes, rationalised. Very roughly, planning to do the following: Set RC7 to digital o/p. Replace movwf TXREG with a function. Function should set RC7 high, transmit working register, then set RC7 low. I'm not sure if I'll need to add a delay. Is this the correct approach in your opinion? Please advise. I'm not sure if I'll have enough space.
-
"removed" means "rationalised" :-) Before you add the the port control. What is the pusedo code ?
-
Yes TBL still works with code removed
-
Does the TBL still work? That is an important test.
-
Hi Anobium, I have reduced the size of my program, please see attached .asm file. Now I will begin working on RC7 control. Thanks & regards,
-
Hi Anobium, Unfortunately no baud rate would work to allow communications between the bootloader and the GUI with a manipulated spbrg value. I will now look through the code to see if an alternative instruction can be removed to free more space. I will update if I find anything. Thanks& regards
-
Change the config to a higher frequency. You can change again in your user program. Try to get those words removed. Let me if you sort.
-
Hi Anobium, Thanks for your suggestions. I have implemented points 2, 3, 4. Unfortunately, removing OSSCON instruction means that I'm operating at the default internal oscillator value of 1MHz. I have tried dividing spbrg_value by whole numbers close to 16 but unfortunately the bit time isn't close enough to the original to allow the GUI to recognise the 0x61 value correctly. I have attached the ASM file. Having implemented points 2, 3, and 4, I can confirm that the bootloader is working as expected....
-
Hi Anobium, Thanks for your suggestions. I have implemented points 2, 3, 4. Unfortunately, removing OSSCON instruction means that I'm operating at the default internal oscillator value of 1MHz. I have tried dividing spbrg_value by whole numbers close to 16 but unfortunately the bit time isn't close enough to the original to allow the GUI to recognise the 0x61 value correctly. I have attached the ASM file. Having implemented points 2, 3, and 4, I can confirm that the bootloader is working as expected....
-
Hi Anobium, Thanks for your suggestions. I have implemented points 2, 3, 4. Unfortunately, removing OSSCON instruction means that I'm operating at the default internal oscillator value of 1MHz. I have tried dividing spbrg_value by whole numbers close to 16 but unfortunately the bit time isn't close enough to the original to allow the GUI to recognise the 0x61 value correctly. I have attached the ASM file. Having implemented points 2, 3, and 4, I can confirm that the bootloader is working as expected....
-
Ok. As this works and all you need to do is add RC7 control then do this. This will reduce the size of the TBL. Make the changes and test, hopefully still works. So, then, you should have the deadroom for your changes with changing the 100 words. Set the config to the internal oscillator to 16mHz, then, remove the OSSCON instruction Remove clrf cnt2 & clrf cnt3 as these will be zero after a POR Remove movlw 0x07 ;clear Analog port 11 bit, rest (8,9,10) as after hard reset movwf ANSELH ; configure...
-
Yes so the hex code, which toggles a pin worked for the bootloader code when I used RS232. The hex is unchanged and is below: :020000040000FA :040000000CEF00F011 :1000080004829EA003D09E90010E036E04921100FC :100018003DEF00F030EC00F00304D8A4FDD78B8C42 :10002800080E026E9E0E016E4C0E0400E82EFDD7DF :10003800012EFBD7022EF9D78B9C080E026E9E0E5E :10004800016E4C0E0400E82EFDD7012EFBD7022EC0 :10005800F9D7000E036EE0D7700ED36E949C8B9C7C :10006800D09E000EF26EF28EF28C9E909D80CD8016 :0E0078001200036A0490049200010EEF00F0E3...
-
Can I confirm? - this is tbl firmware that works with rs232? - this is using rs232 ? Go back to the rs232 firmware with a stock PICCODES.INI - does this work? I would like to get back to something that works as a baseline.
-
I have tried with 0.14.6.5 of the PC software and default as transfer size. Check Device... Open COM10 serial port at 19200bd Hardware RTS reseting Device Device answer: 0x61 0x43='C' byte OK, now check ID-code and Family... idCode = $61 family = C description = 18F w/8KB flash & 256B EEPROM flash mem = 8192 bytes EEPROM mem = 256 bytes Bootloader size = 260 bytes Transfert block size = 64 bytes Found: 18F w/8KB flash & 256B EEPROM Open HEX file: C:\Projects\TESTforBTLR.X\dist\default\production\TESTforBTLR.X.production.hex...
-
So I can't seem to write to the device when the block size is default, but transfer will begin with block size of 8. I have tried with 0.14.6.5 of the PC software hecking device Open COM10 serial port at 19200 Baud Rate Hardware RTS resetting device Device answer: 0x61 0x43='C' byte OK, now check ID-code and Family idCode = $61 family = C description = 18F w/8KB flash & 256B EE flash mem = 8192 bytes EEPROM mem = 256 bytes Bootloader size = 200 bytes Transfer block size = 64 bytes Device detected:18F...
-
Thanks Revert the block size. If the block size worked when using RS232 then why change? Test and post results.
-
Hello, Thank you for getting back to me. I have attached the ASM file to my original post, LST file attached here. I think my Bootloader GUI must be very old, it's v0.11.0. I modified my piccodes.ini file as since modifying the bootloader for RS485 increased it's size, also write/erase block sizes in the pic18f13k22 data sheet say the write block is 8 bytes. The only modification was to $61, as below: $61, C, 18F w/8KB flash & 256B EEPROM, $2000, $100, 260, 8,
-
Hi there, I'm trying to modify the bootloader to work on RS485 for PIC18F13K22. I originally confirmed my setup of the bootloader and application code (toggle a pin) works over RS232 before modifying the bootloader firmware for RS485. Currently, the check device works and the bootloader GUI is communicating with the PIC: Check Device... Open COM10 serial port at 19200bd Hardware RTS reseting Device Device answer: 0x61 0x43='C' byte OK, now check ID-code and Family... idCode = $61 family = C description...
-
And, you have a transfer block of 'Transfert block size = 8 bytes' - you must have changed PICCODES.INI ?
-
Post the LST and ASM source. At the moment - no idea. The PC software you are using? How old? It must be the old buggy version. This is latest version. Note the corrected spelling - this should be the baseline. Checking device Open COM2 serial port at 19200 Baud Rate Hardware DTR resetting device Device answer: 0xAA 0x42='B' byte OK, now check ID-code and Family idCode = $AA family = B description = 16F w/8Kw flash & 256BEE (Blk32) flash mem = 16384 bytes EEPROM mem = 256 bytes Bootloader size =...
