 |
 |
| View previous topic :: View next topic |
| Author |
Message |
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
| Record bootloader with Hyperterminal. |
 Posted: Mon Nov 16, 2015 6:49 am |
 |
|
Hello, I'm modifying the Bootloader to read the code from external EEPROM memory.
But before that, I'm trying to write a new firmware through the HyperTerminal to understand how the write commands in bootloader.
I use Siow to write my codes, but I want to write it by hand using hyperterminal or putty.
the question is:
Anyone know how I communicate with the pic of the bootloader to send a new program manually? |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Mon Nov 16, 2015 8:09 am |
|
|
| If you are just doing this for testing, easiest way, open the hex file in Notepad, and copy a line, then paste it into the terminal program. Otherwise the risk of typing errors is just too high. The lines have to be correct, with the checksum right, or they will not be accepted. Even a very simple program will have something like 20+ lines of hex that has to be right to work. |
|
|
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
|
| Posted: Mon Nov 16, 2015 2:27 pm |
|
|
| Ttelmah wrote: | | If you are just doing this for testing, easiest way, open the hex file in Notepad, and copy a line, then paste it into the terminal program. Otherwise the risk of typing errors is just too high. The lines have to be correct, with the checksum right, or they will not be accepted. Even a very simple program will have something like 20+ lines of hex that has to be right to work. |
I have called on putty for example, copied and pasted the lines of the .hex file. but nothing happened!
I wanted to know more details of how is the reception of these data by the pic to learn how to modify to get the data from the external EEPROM.
but still not understood how the pic takes the data. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Nov 16, 2015 2:50 pm |
|
|
Here is how to download a Hex file to the CCS bootloader in a PIC:
First, install TeraTerm. You could probably use Putty, but the instructions
below are for TeraTerm. I know that TeraTerm works.
TeraTerm installation instructions:
http://www.ccsinfo.com/forum/viewtopic.php?t=39388&start=18
Go to the Setup/Serial Port menu in TeraTerm and select Com1, 9600,
N, 8, 1 and set Flow Control to XON/XOFF. This is essential.
Compile Ex_bootloader.c, and program the .HEX file for it into your
PIC, by using your ICD3 or Pickit3 from within MPLAB. Or use a CCS
ICD programmer within the CCS IDE.
Next, compile Ex_bootload.c (This is a different program than Ex_bootloader.c).
Then jumper PIC pin A4 to ground on your board (and leave it jumpered).
Note: The documentation for Ex_bootloader.c says to use Pin B5. But
within the file, the C source code is using Pin A4. If your board has
a push-button on Pin A4, then you don't have to jumper it to ground.
Just press the button and hold it down during the next part, below.
Press the PIC's reset button on your board. (Disconnect the ICD
programmer before doing this, and leave it disconnected). The PIC will go
into the mode where it's expecting to receive the application program's
HEX file. This is Ex_bootload.hex (NOT Ex_bootloader.hex).
Then go to the File menu in TeraTerm and click on Send File. Select
the Ex_bootload.hex file. If you double click on the .Hex file, it will
be sent automatically, almost instantly, and the output will start
appearing in the TeraTerm window. The expected output from
Ex_bootload.hex is a bunch of continuously incrementing numbers. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Mon Nov 16, 2015 3:07 pm |
|
|
I got the impression he wanted to do things a 'little at a time', so he could possibly stop with a debugger between lines. Hence the 'cut and paste suggestion'.  |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Nov 16, 2015 3:21 pm |
|
|
I thought or hoped he could take one line of a hex file and send that,
using the described method. He could send a very short hex file. |
|
|
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
|
| Posted: Thu Nov 19, 2015 5:48 pm |
|
|
| Ttelmah wrote: | | I got the impression he wanted to do things a 'little at a time', so he could possibly stop with a debugger between lines. Hence the 'cut and paste suggestion'. |
Exact!
I want to modify the bootloader to read data from the EEPROM!
I already started doing this!
Loader.c modified the file to read the data from the external EEPROM that contains the lines of a new program that are in the .hex file.
this is the code:
loader.c
| Code: |
while (!done) // Loop until the entire program is downloaded
{
buffidx = 0; // Read into the buffer until 0x0D ('\r') is received or the buffer is full
flag_primeiro=1;
for (J = 0; J < 64; J++) {
buffer[J] = NULL;
}
do {
//buffer[buffidx] = getc();
aux_eeprom = read_ext_eeprom(contador);
if((aux_eeprom == ':') && (flag_primeiro == 0)){BREAK;}
if(aux_eeprom == 'O'){
if(read_ext_eeprom(contador+1) == 'K'){BREAK;}
}
buffer[buffidx] = aux_eeprom;
contador = contador + 1;
flag_primeiro=0;
} while ( (buffer[buffidx++] != 0x0D) && (buffidx <= BUFFER_LEN_LOD) );
putchar (XOFF); // Suspend sender
|
the program le the variables correctly, but not finish recording, do not know why.
this is my .hex:
: 0406400037EF03F09D
: 08064800EA6A050EE96EEF50AD
: 100650000DE0060E016E006A002EFED7012EFBD7BC
: 100660007B0E006E002EFED7EF2EF3D71200F86A35
: 10067000D09EB8862A0EAF6E000EB06EA60EAC6E7F
: 10068000900EAB6EC150C00B0F09C16E840ED56EBB
: 10069000F29AF298F096F0989D9AF29CF29EF2BE31
: 1006A000FDD794928B92939A8A8A640E056ECCDF62
: 0E06B000939A8A9A640E056EC7DFF5D7030091
: 020000040030CA
: 0E00000000C2180E0084810000C03FE03F40A7
: 00000001FF
; PIC18LF2685
; CRC = 2444 CREATED = "18-Nov-15 13:33"
but I just saved in the external EEPROM lines that have ":".
You are missing something. I could not find it.
perhaps a termination command transfer.
can you help me? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Fri Nov 20, 2015 2:24 am |
|
|
Carriage returns.
Remember these exist between the lines, and are what the bootloader code looks for to mark the end of line. Similarly, if cutting and pasting, you would need to send a 'return' after each line. |
|
|
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
|
| Posted: Fri Nov 20, 2015 9:19 am |
|
|
| Ttelmah wrote: | Carriage returns.
Remember these exist between the lines, and are what the bootloader code looks for to mark the end of line. Similarly, if cutting and pasting, you would need to send a 'return' after each line. |
i make this, but dont work.
| Code: |
if((aux_eeprom == ':') && (flag_primeiro == 0)){buffer[buffidx] = 0x0D;BREAK;}
if(aux_eeprom == 'O'){
if(read_ext_eeprom(contador+1) == 'K'){buffer[buffidx] = 0x0D;BREAK;}
}
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Fri Nov 20, 2015 11:48 am |
|
|
If I am understanding what you are doing, you are then losing the ':', which the parser also requires.
It does seem to be a horrendously complex/dangerous way of doing this. Whatever you use to generate the EEPROM, should be interpreting the hex as it arrives (as the bootloader does), and just writing the real data to the EEPROM.
When the data is complete, and the checksum works, it then sets a marker in a reserved area in the EEPROM to say that the data has been checked. The bootloader can then just directly read the EEPROM data and program from it.
Trying to interpret the data from the EEPROM, implies the data has not been checked as it was written, and implies the bootloader could start programming, with data that later goes wrong, corrupting the chip. Not good. |
|
|
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
|
| Posted: Fri Nov 20, 2015 12:44 pm |
|
|
| Ttelmah wrote: | If I am understanding what you are doing, you are then losing the ':', which the parser also requires.
It does seem to be a horrendously complex/dangerous way of doing this. Whatever you use to generate the EEPROM, should be interpreting the hex as it arrives (as the bootloader does), and just writing the real data to the EEPROM.
When the data is complete, and the checksum works, it then sets a marker in a reserved area in the EEPROM to say that the data has been checked. The bootloader can then just directly read the EEPROM data and program from it.
Trying to interpret the data from the EEPROM, implies the data has not been checked as it was written, and implies the bootloader could start programming, with data that later goes wrong, corrupting the chip. Not good. |
I'm not losing ":".
I'm using the marker next package to end the previous! understood?
the character ":" is there
you are right! I need to write the data as the bootloader need! that's how I tried to do, I recorded all the lines with the marker ":" in sequence and at the end of every packet, I put an OK to signal the end of the program.
I do not understand why it did not work like that!
Might have a finalization command, I do not know.
You said you need to write the ckecksum in EEPROM? The checksum which has within the .HEX?
But I did not see that part of the program that uses it.
I thought the lines were "" as a marker, were not used, they are used? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Fri Nov 20, 2015 3:33 pm |
|
|
Assuming you are receiving this from something, and writing it to the EEPROM, you need to check on receipt that it is good, before attempting to start the loading.
You need to actually decode every line, and check it's checksum, and then check the checksum of the entire ROM, before initiating the load.
Understand that a conventional 'bootloader' is done with the PIC attached to a PC, and therefore with very limited risk of data corruption. If it does fail, it can just be run again. With data written from an EEPROM, that is loaded perhaps from a modem or something, the data must be 99.9999% verified, before you trigger the load, otherwise (since the bootloader will not be what handles the load), if the data is corrupted, the processor becomes effectively useless, with part of it's program corrupted.....
The approach is fundamentally flawed. |
|
|
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
|
| Posted: Sat Nov 21, 2015 9:22 am |
|
|
| Ttelmah wrote: | Assuming you are receiving this from something, and writing it to the EEPROM, you need to check on receipt that it is good, before attempting to start the loading.
You need to actually decode every line, and check it's checksum, and then check the checksum of the entire ROM, before initiating the load.
Understand that a conventional 'bootloader' is done with the PIC attached to a PC, and therefore with very limited risk of data corruption. If it does fail, it can just be run again. With data written from an EEPROM, that is loaded perhaps from a modem or something, the data must be 99.9999% verified, before you trigger the load, otherwise (since the bootloader will not be what handles the load), if the data is corrupted, the processor becomes effectively useless, with part of it's program corrupted.....
The approach is fundamentally flawed. |
Got it!
you're right!
Now I'm trying to learn to read from and write to the EEPROM using the pic bootloader. I want to complete this step is giving error and do not know why, I'll see if something has corrupted!
when I get it, I will work to check data when you transfer using modem.
I recorded the pic using the attached cable into the computer and using another serial cable, I read what the pc sent to the pic!
ole the communication:
This is what the pc sent to the bootloader:
:0406400037EF03F09D
:08064800EA6A050EE96EEF50AD
:100650000DE0060E016E006A002EFED7012EFBD7BC
:100660007B0E006E002EFED7EF2EF3D71200F86A35
:10067000D09EB8862A0EAF6E000EB06EA60EAC6E7F
:10068000900EAB6EC150C00B0F09C16E840ED56EBB
:10069000F29AF298F096F0989D9AF29CF29EF2BE31
:1006A000FDD794928B92939A8A8A640E056ECCDF62
:0E06B000939A8A9A640E056EC7DFF5D7030091
:020000040030CA
:0E00000000C2180E0084810000C03FE03F40A7
;898F
:00000001FF
this is .HEX I used:
:0406400037EF03F09D
:08064800EA6A050EE96EEF50AD
:100650000DE0060E016E006A002EFED7012EFBD7BC
:100660007B0E006E002EFED7EF2EF3D71200F86A35
:10067000D09EB8862A0EAF6E000EB06EA60EAC6E7F
:10068000900EAB6EC150C00B0F09C16E840ED56EBB
:10069000F29AF298F096F0989D9AF29CF29EF2BE31
:1006A000FDD794928B92939A8A8A640E056ECCDF62
:0E06B000939A8A9A640E056EC7DFF5D7030091
:020000040030CA
:0E00000000C2180E0084810000C03FE03F40A7
:00000001FF
;PIC18LF2685
;CRC=2444 CREATED="21-nov-15 13:04"
the difference between them is the part in red, did not understand this part! it is not an error, because it always happens. |
|
|
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
|
| Posted: Sun Nov 22, 2015 2:55 pm |
|
|
| Can anyone help? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Nov 22, 2015 3:06 pm |
|
|
It's a hex file comment. It should be ignored by the bootloader in the PIC.
The file 'loader.c' says this:
| Quote: | // Only process data blocks that start with ':'
if (rBuffer[0].buffer[0] == ':')
{
|
Since that line starts with ';', the code will ignore it. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
