Searching \ for '[PIC] PIC24 FLASH word programming mode and simula' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'PIC24 FLASH word programming mode and simula'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC24 FLASH word programming mode and simula'
2011\03\24@221716 by Isaac Marino Bavaresco

flavicon
face
Dear All,

I am writing a boot-loader for the PIC24FJ192GA108 and I'm facing a
problem. Although the data-sheet (DS39905E) says that it can be
programmed one word at a time (page 63), the simulator (MPLAB SIM) keeps
issuing the following error in the "MPLAB SIM" pane of the output window:

"CORE-W0006: An Invalid Programming mode was selected. No Programming
operation occurred"
....
"MAXIMUM number of warnings/errors exceeded 200, program execution halted."


This is the source code for MPLAB C30:

#define PM_WORD_WRITE    0x4003
....
   NVMCON        = PM_WORD_WRITE;

   TBLPAG        = (unsigned char)( Address >> 16 );

   __builtin_tblwtl( (unsigned short)Address, ValueLow );
   __builtin_tblwth( (unsigned short)Address, ValueHigh );

   asm( "disi #5" );

   __builtin_write_NVM();


I generally trust the MPLAB SIM, but in this specific case it seems to
have a bug. Did somebody face this same problem already?


Best regards,

Isaac

2011\03\25@110744 by Isaac Marino Bavaresco

flavicon
face
Interesting, this is THE PICLIST and my PIC post didn't receive any
response yet, although there are several ongoing discussions under other
tags.

The PIC tag got just 2 messages in the last 36 hours.

Perhaps it's time to change the name of the list to "OT: random
discussions loosely related to technology."


Isaac


Em 24/3/2011 23:17, Isaac Marino Bavaresco escreveu:
{Quote hidden}

>

2011\03\25@114817 by M.L.

flavicon
face

On Thu, Mar 24, 2011 at 10:17 PM, Isaac Marino Bavaresco
<spam_OUTisaacbavarescoTakeThisOuTspamyahoo.com.br> wrote:

>
> This is the source code for MPLAB C30:
>
> #define PM_WORD_WRITE    0x4003


I wouldn't trust C30 to give you what you think you're getting, when
dealing with something that requires instruction-level compilation
accuracy. I say this as someone who generally likes C30.
I'd rewrite the code in assembly and see if it works.
--
Martin K.

2011\03\25@114951 by alan.b.pearce

face picon face
>
> Interesting, this is THE PICLIST and my PIC post didn't receive any
> response yet, although there are several ongoing discussions under other
> tags.
>
> The PIC tag got just 2 messages in the last 36 hours.
>
> Perhaps it's time to change the name of the list to "OT: random
> discussions loosely related to technology."
>
>
> Isaac

Yeah, it is a bit like that.

My immediate reaction on reading your first post was 'have you checked the code in the Microchip application code library'?

After all Microchip do have two boot loaders, one serial and one USB, and I understand the latter is pretty robust, although I don't have any experience with it. A look through the code does seem to say it ought to be alright though.
-- Scanned by iCritical.

2011\03\25@120858 by Olin Lathrop

face picon face
Isaac Marino Bavaresco wrote:
> Interesting, this is THE PICLIST and my PIC post didn't receive any
> response yet,
> <remainder of whine snipped>

I saw your post but didn't respond because:

1 - The obvious thing to do is to try it in a real chip.  For some
   reason you didn't seem to do this and I didn't feel like writing
   a post "So try it in a real chip, duh.".

2 - I saw C code.  I generally avoid helping people when they
   program in C because I don't want to spend time on possible
   compiler problems, and don't want to spend time on people that
   may not be interested in learning the low level details.  I'm
   not saying you don't, but since the example is in C, the chances
   are greater.

3 - The error message was complaining about a "mode", which is
   probably the NVMCON opcode, but I didn't see you pay any
   attention to the information the system was already giving you
   or show us the NVMCON value.  I didn't feel like playing 20
   questions, and it seemed to me you were just throwing up your
   hands and calling for help before having exhausted reasonable
   means at your disposal to diagnose the problem.

4 - You didn't even say which line of code caused the error.  That's
   a so blantantly obvious piece of important information that I felt
   your level of diagnostic skill was going to make getting into this
   too much trouble, with lots of back and forth just to get basic
   information you should have seen was necessary for yourself.

So I hit delete and moved on.

To all those that always say you shouldn't reply when you don't have
anything useful to say, here is a example where I did exactly that.  See
what happens?  The OP had no idea why nobody replied.  To anyone who now
feels the need to complain about this post: First, he asked.  Second, I
originally didn't respond and that didn't work.  You can't have it both
ways.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\03\25@121531 by Isaac Marino Bavaresco

flavicon
face
Em 25/3/2011 12:48, .....alan.b.pearceKILLspamspam@spam@stfc.ac.uk escreveu:
>> Interesting, this is THE PICLIST and my PIC post didn't receive any
>> response yet, although there are several ongoing discussions under other
>> tags.
>>
>> The PIC tag got just 2 messages in the last 36 hours.
>>
>> Perhaps it's time to change the name of the list to "OT: random
>> discussions loosely related to technology."
>>
>>
>> Isaac
> Yeah, it is a bit like that.
>
> My immediate reaction on reading your first post was 'have you checked the code in the Microchip application code library'?
>
> After all Microchip do have two boot loaders, one serial and one USB, and I understand the latter is pretty robust, although I don't have any experience with it. A look through the code does seem to say it ought to be alright though.


The boot-loader is not yet finished but I did some tests in the real
hardware today, and they show that the word-programming works.


Best regards,

Isaa

2011\03\25@122646 by Olin Lathrop

face picon face
Isaac Marino Bavaresco wrote:
> The boot-loader is not yet finished but I did some tests in the real
> hardware today, and they show that the word-programming works.

I have done bootloaders for dsPIC parts.  These have to erase a whole erase
block at a time.  My bootloaders then write whole write blocks within each
erase block.  So far that seems to have worked without incident.  I don't
see why a bootloader would want to write individual words.

I think that could wear out the flash faster too.  It's possible that each
word write effects the whole write block.  If a write block is 32 words in
size, then writing each word individually may stress the flash as if the
whole block were written 32 times.  I don't know if this is true, but I can
certainly see how it could be.

Again, word writes don't make much sense for a bootloader.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\03\25@125316 by Harold Hallikainen

face
flavicon
face

{Quote hidden}

I've had a 24H bootloader working for several years. I wrote assembly
routines that I call from C. The routines are:

_ReadFlashLocal:
; 32 bit input passed in W1:W0, 32 bit result returned in W1:W0
       mov                W1,TBLPAG
       TBLRDH        [W0],W1                                                        ; high byte of contents into W1
       TBLRDL        [W0],W0                                                        ; low word into W0
       return

_UnlockPM:
; Unlock Program Memory
       push        w0                ; save it
       disi        #5                ; disable interrupts for next 5 instructions
       mov                #0x55,w0
       mov                w0,NVMKEY ; first part of magic number
       mov                #0xaa,w0
       mov                w0,NVMKEY ; second part
       bset        NVMCON,#15        ;start write
       nop
       nop
       btsc        NVMCON,#15
       bra                $-2                        ; write not done yet, go again
       pop                w0                        ; restore it
       return

_EraseFlashPageLocal:
; Pass in a 32 bit address in w1:w0. This will erase 512 instruction
locations (1024 addresses). For erase, the address bits are interpreted as
; pppp ppoo oooo oooo where p is page, and o is offset. Therefore, the
10lsb of the address passed in to this routine have no effect, but are
; used here to provide a consistent interface (always pass in a 32 bit
address).
       mov                W1, TBLPAG                ; set up the page
       tblwtl        W0,[W0]                        ; a dummy write in the page we are going to erase
       mov                #0x4042,W0
       mov                W0,NVMCON                ; set up for page erase
   call        _UnlockPM                ; go do the erase
       return

_WriteFlashWordLocal:
; Pass a 32 bit address in W1:W0 and a 32 bit value in W3:W2. This writes
the data to the write latch but does not actually program the chip. 64 24
bit words
; can be written before you have to do a WriteFlashRow.
       mov                W1,TBLPAG                ; select the page we're going to write to
       TBLWTL        W2,[W0]                        ; write low byte of data in w2 to offset pointed to by w0
       TBLWTH        W3,[W0]                        ; write high byte of data in w3 to offset pointed to by w0
       return

_WriteFlashRowLocal:
; No arguments are passed in. The row to program is determined by the
previous TBLWT instructions.
       mov                #0x4001, W0
       mov                W0,NVMCON                ; Tell NVMCON we're going to write a row
   call        _UnlockPM                ; go do the write
       return


Harold




-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2011\03\25@134259 by Isaac Marino Bavaresco

flavicon
face
Em 25/3/2011 13:27, Olin Lathrop escreveu:
> Isaac Marino Bavaresco wrote:
>> The boot-loader is not yet finished but I did some tests in the real
>> hardware today, and they show that the word-programming works.
> I have done bootloaders for dsPIC parts.  These have to erase a whole erase
> block at a time.  My bootloaders then write whole write blocks within each
> erase block.  So far that seems to have worked without incident.  I don't
> see why a bootloader would want to write individual words.
>
> I think that could wear out the flash faster too.  It's possible that each
> word write effects the whole write block.  If a write block is 32 words in
> size, then writing each word individually may stress the flash as if the
> whole block were written 32 times.  I don't know if this is true, but I can
> certainly see how it could be.
>
> Again, word writes don't make much sense for a bootloader.


This is a different boot-loader, it is for a client's existing board,
which I didn't design. It first receives all the firmware, then checks
the firmware for errors (CRC) and finally program it to the FLASH memory.

The application is wireless-connected with intermittent availability (a
few minutes each hour), and the application cannot be stopped for too long.

The board has external FLASH, but just a moderate amount, so I couldn't
use it to buffer the firmware. Luckily, the client's application uses
only a small fraction of the PIC's FLASH, so I decided to use half of
the program memory to store the firmware as it is being received.


My boot-loader inter-operates with the application. When the application
receives packets that are for the boot-loader, it calls a function
inside the boot-loader which saves the packet. When the boot-loader
receives the last packet and validates the firmware, it doesn't return
to the application and do the real programming.

I use word-writes to register in an array of words what blocks were
already received. The blocks may be received in any order and there is a
mechanism to tell the server what blocks are still needed.


Best regards,

Isaac

2011\03\25@134621 by Isaac Marino Bavaresco

flavicon
face
Em 25/3/2011 13:27, Olin Lathrop escreveu:
> Isaac Marino Bavaresco wrote:
>> The boot-loader is not yet finished but I did some tests in the real
>> hardware today, and they show that the word-programming works.
> I have done bootloaders for dsPIC parts.  These have to erase a whole erase
> block at a time.  My bootloaders then write whole write blocks within each
> erase block.  So far that seems to have worked without incident.  I don't
> see why a bootloader would want to write individual words.
>
> I think that could wear out the flash faster too.  It's possible that each
> word write effects the whole write block.  If a write block is 32 words in
> size, then writing each word individually may stress the flash as if the
> whole block were written 32 times.  I don't know if this is true, but I can
> certainly see how it could be.
>
> Again, word writes don't make much sense for a bootloader.


Word-writes serve other purposes also. Microchip has an EEPROM-emulation
library for devices without internal EEPROM, but it only works for
devices that accept word-writes.


Best regards,

Isaa

2011\03\25@135709 by Isaac Marino Bavaresco

flavicon
face
Em 25/3/2011 13:09, Olin Lathrop escreveu:
> Isaac Marino Bavaresco wrote:
>> Interesting, this is THE PICLIST and my PIC post didn't receive any
>> response yet,
>> <remainder of whine snipped>
> I saw your post but didn't respond because:
>
> 1 - The obvious thing to do is to try it in a real chip.  For some
>     reason you didn't seem to do this and I didn't feel like writing
>     a post "So try it in a real chip, duh.".


At that time I didn't have the board in-hand. This morning I received
one board and could see that my routines work correctly, so the bug is
in the simulator.


> 2 - I saw C code.  I generally avoid helping people when they
>     program in C because I don't want to spend time on possible
>     compiler problems, and don't want to spend time on people that
>     may not be interested in learning the low level details.  I'm
>     not saying you don't, but since the example is in C, the chances
>     are greater.


The Microchip boot-loaders are supplied as C source code.


> 3 - The error message was complaining about a "mode", which is
>     probably the NVMCON opcode,


There is no NVMCON opcode, NVMCON is a register that is written with the
requested programming mode.


>  but I didn't see you pay any
>     attention to the information the system was already giving you
>     or show us the NVMCON value.


In the source code:

{Quote hidden}

Sorry, I forgot to say that the message was being issued when the line
"__builtin_write_NVM();" was executed. This pseudo-function does exactly
the programming sequenced recommended by Microchip.


{Quote hidden}

I agree with you, your behavior was perfectly correct and I don't have
any complains about it. I was just making a comment about the list as a
whole.


Best regards,

Isaac

2011\03\25@140228 by Isaac Marino Bavaresco

flavicon
face
Em 25/3/2011 12:47, M.L. escreveu:
> On Thu, Mar 24, 2011 at 10:17 PM, Isaac Marino Bavaresco
> <isaacbavarescospamKILLspamyahoo.com.br> wrote:
>
>> This is the source code for MPLAB C30:
>>
>> #define PM_WORD_WRITE    0x4003
>
> I wouldn't trust C30 to give you what you think you're getting, when
> dealing with something that requires instruction-level compilation
> accuracy.


MPLAB C30 offers the pseudo-function "__builtin_write_NVM()". It does
the exact sequence recommended by Microchip, and it is used in
Microchip's own boot-loaders.


> I say this as someone who generally likes C30.
> I'd rewrite the code in assembly and see if it works.


The problem was that I didn't have access to a real board at that time,
I was using the simulator.



Best regards,

Isaac

2011\03\25@140955 by Olin Lathrop

face picon face
Isaac Marino Bavaresco wrote:
> I use word-writes to register in an array of words what blocks were
> already received.

Huh?

> The blocks may be received in any order and there
> is a mechanism to tell the server what blocks are still needed.

But that only applies to the order the blocks are temporarily saved in your
buffer space.  The bootloader doesn't run until all the blocks are buffered,
so it can write the app image in sequential order.  None of this explains
why word write are necessary, as apposed to page writes.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\03\25@141136 by Olin Lathrop

face picon face
Isaac Marino Bavaresco wrote:
>> Again, word writes don't make much sense for a bootloader.
>
> Word-writes serve other purposes also. Microchip has an
> EEPROM-emulation library for devices without internal EEPROM, but it
> only works for devices that accept word-writes.

None of which has anything to do with a bootloader.

By the way, my EEPROM emulation routines for the 24 bit core don't use word
writes.

2011\03\25@143105 by Isaac Marino Bavaresco

flavicon
face
Em 25/3/2011 15:10, Olin Lathrop escreveu:
> Isaac Marino Bavaresco wrote:
>> I use word-writes to register in an array of words what blocks were
>> already received.
> Huh?
>
>> The blocks may be received in any order and there
>> is a mechanism to tell the server what blocks are still needed.
> But that only applies to the order the blocks are temporarily saved in your
> buffer space.  The bootloader doesn't run until all the blocks are buffered,
> so it can write the app image in sequential order.  None of this explains
> why word write are necessary, as apposed to page writes.


How can the boot-loader tell if a block full of 0xff was present in the
middle of the application

2011\03\25@143739 by Isaac Marino Bavaresco

flavicon
face
Em 25/3/2011 15:31, Isaac Marino Bavaresco escreveu:
> Em 25/3/2011 15:10, Olin Lathrop escreveu:
>> Isaac Marino Bavaresco wrote:
>>> I use word-writes to register in an array of words what blocks were
>>> already received.
>> Huh?
>>
>>> The blocks may be received in any order and there
>>> is a mechanism to tell the server what blocks are still needed.
>> But that only applies to the order the blocks are temporarily saved in your
>> buffer space.  The bootloader doesn't run until all the blocks are buffered,
>> so it can write the app image in sequential order.  None of this explains
>> why word write are necessary, as apposed to page writes.
>
> How can the boot-loader tell if a block full of 0xff was present in the
> middle of the application?


Oops, hit 'send' too early by accident.


If I don't register somewhere each block as it is received, the only way
to tell if a block was already received would be to scan it from begin
to end to find a value different to 0xff.
Besides being too time-consuming, if a block full of 0xff is received it
will always be detected as not received.


Best regards,

Isaac

2011\03\25@170526 by Olin Lathrop

face picon face
Isaac Marino Bavaresco wrote:
> How can the boot-loader tell if a block full of 0xff was present in
> the middle of the application?

Um, by checking it.

However, does it really matter?  A whole block set to the erased value in
the middle of the app image is going to be rare, since the linker starts
filling program memory from the beginning, generally without leaving gaps.
If bootload speed is really critical and your app is expected to have large
tables often set to the erased value, then checking for a whole block set to
all 1s might make sense.  If these conditions are not met, there is little
advantage and the extra code just adds extra risk of a bug.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\03\25@170814 by Olin Lathrop

face picon face
Isaac Marino Bavaresco wrote:
> If I don't register somewhere each block as it is received, the only
> way
> to tell if a block was already received would be to scan it from begin
> to end to find a value different to 0xff.
> Besides being too time-consuming, if a block full of 0xff is received
> it
> will always be detected as not received.

OK, so you use a single erase block somewhere with individual bits
corresponding to uploaded blocks.  These bits start out as 1 and you flip
them to 0 when the corresponding block is received.  In any case, you should
checksum the whole uploaded image before attempting to write it to the app
area.

However, what does this have to do with the bootloader doing word versus
page writes?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\03\25@173522 by Dwayne Reid

flavicon
face
At 03:08 PM 3/25/2011, Olin Lathrop wrote:

>However, what does this have to do with the bootloader doing word versus
>page writes?

From an earlier message from the Original Poster:

>My boot-loader inter-operates with the application. When the application
>receives packets that are for the boot-loader, it calls a function
>inside the boot-loader which saves the packet. When the boot-loader
>receives the last packet and validates the firmware, it doesn't return
>to the application and does the real programming.

In other words, his boot-loader is responsible for saving the new firmware to scratchpad FLASH as it received.  That requires word writes.

dwayne

-- Dwayne Reid   <.....dwaynerKILLspamspam.....planet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2011\03\25@175430 by Olin Lathrop

face picon face
Dwayne Reid wrote:
> In other words, his boot-loader is responsible for saving the new
> firmware to scratchpad FLASH as it received.  That requires word
> writes.

I don't consider that a "bootloader" function.  It's really a uploader
function that he happened to put in the bootloader code.

In any case, I still don't see why word writes are necessary.  First, it
would make sense for the upload blocks to be the same size as the write
blocks.  However, even if that is not possible or desirable, I would expect
the whole upload area to be erased once before any blocks are uploaded.
Then blocks are written as received without any erases.  Even if partial
pages are written, it still makes sense to use page writes.  Even if you're
writing just two words in a page, why would you do two separate word writes
when they can be written at the same time with a single page write?  It
doesn't make sense.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\03\25@180224 by Isaac Marino Bavaresco

flavicon
face
Em 25/3/2011 18:08, Olin Lathrop escreveu:
> Isaac Marino Bavaresco wrote:
>> If I don't register somewhere each block as it is received, the only
>> way
>> to tell if a block was already received would be to scan it from begin
>> to end to find a value different to 0xff.
>> Besides being too time-consuming, if a block full of 0xff is received
>> it
>> will always be detected as not received.
> OK, so you use a single erase block somewhere with individual bits
> corresponding to uploaded blocks.


Not bits, one word per block, because I can program a minimum of one
word at a time.
It is a little wasteful but that doesn't matter at all because there is
plenty of unused FLASH.

The device has 128k instructions plus 3k spare for the boot-loader.

The area from 0 to 63k-1 instructions is reserved for the application.

>From 63k to 64k-1 is reserved for the copy of the application's saved
reset vector (goto instruction to the start of the application), which
is replaced in row 0 by the reset vector of the boot-loader. This area
is mostly empty.

>From 64k to 127k-1 is reserved for the new firmware being downloaded. It
is an exact copy of the final firmware, shifted up 64k instructions.
>From 127k to 128k-1 is reserved for register the received blocks and
other control information (number of blocks expected, CRC of the whole
new firmware, version of the new firmware, etc.)

The boot-loader is located from 128k to the end of the memory.


>   These bits start out as 1 and you flip
> them to 0 when the corresponding block is received.  In any case, you should
> checksum the whole uploaded image before attempting to write it to the app
> area.
>
> However, what does this have to do with the bootloader doing word versus
> page writes?


The word programming is to mark each entry of the received-block list.


Isaac

2011\03\25@181029 by Olin Lathrop

face picon face
Isaac Marino Bavaresco wrote:
>> OK, so you use a single erase block somewhere with individual bits
>> corresponding to uploaded blocks.
>
> Not bits, one word per block, because I can program a minimum of one
> word at a time.
> It is a little wasteful but that doesn't matter at all because there
> is plenty of unused FLASH.

If you have the space it doesn't matter, but you can write individual bits
since you'd only be flipping them from 1 to 0.

> The word programming is to mark each entry of the received-block list.

As I thought, this isn't really part of the bootload process.  This is a
function of the uploader, some of the code of which you apparently put in
the bootloader module.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\03\25@183418 by Isaac Marino Bavaresco

flavicon
face
Em 25/3/2011 19:10, Olin Lathrop escreveu:
> Isaac Marino Bavaresco wrote:
>>> OK, so you use a single erase block somewhere with individual bits
>>> corresponding to uploaded blocks.
>> Not bits, one word per block, because I can program a minimum of one
>> word at a time.
>> It is a little wasteful but that doesn't matter at all because there
>> is plenty of unused FLASH.
> If you have the space it doesn't matter, but you can write individual bits
> since you'd only be flipping them from 1 to 0.


I'm not sure if it is safe to write each word more than once without
erasing, even to just turn bits from 1 to 0.


>> The word programming is to mark each entry of the received-block list.
> As I thought, this isn't really part of the bootload process.  This is a
> function of the uploader, some of the code of which you apparently put in
> the bootloader module.


Call it as you like, but when this routine saves the last block, it
transfers the firmware to its final location and resets the processor.


Isaac

2011\03\25@184508 by Isaac Marino Bavaresco

flavicon
face
Em 25/3/2011 18:54, Olin Lathrop escreveu:
> Dwayne Reid wrote:
>> In other words, his boot-loader is responsible for saving the new
>> firmware to scratchpad FLASH as it received.  That requires word
>> writes.
> I don't consider that a "bootloader" function.  It's really a uploader
> function that he happened to put in the bootloader code.
>
> In any case, I still don't see why word writes are necessary.  First, it
> would make sense for the upload blocks to be the same size as the write
> blocks.


Yes, the upload blocks are the same size of a program row (64
instructions or 192 bytes)



>   However, even if that is not possible or desirable, I would expect
> the whole upload area to be erased once before any blocks are uploaded.


Yes, the whole temporary area is erased when a special block (called
header) is received and the process begins.
This block also contains the CRC of the whole new firmware, a number to
identify the version of the firmware and the number of blocks to be
received and programmed.

Each block (header of program) has its own CRC also.


> Then blocks are written as received without any erases.  Even if partial
> pages are written, it still makes sense to use page writes.  Even if you're
> writing just two words in a page, why would you do two separate word writes
> when they can be written at the same time with a single page write?  It
> doesn't make sense.

The blocks (rows) of 192 bytes are programmed using page writes, but one
additional word write is made to a different
area to signal that that particular block was received.


Isaac

2011\03\25@190612 by Isaac Marino Bavaresco

flavicon
face
Em 25/3/2011 19:45, Isaac Marino Bavaresco escreveu:
> Each block (header of program) has its own CRC also.

Oops! "header *OR* program".

2011\03\26@075444 by M.L.

flavicon
face
On Fri, Mar 25, 2011 at 2:02 PM, Isaac Marino Bavaresco
<EraseMEisaacbavarescospam_OUTspamTakeThisOuTyahoo.com.br> wrote:
> MPLAB C30 offers the pseudo-function "__builtin_write_NVM()". It does
> the exact sequence recommended by Microchip, and it is used in
> Microchip's own boot-loaders.

That's fine, but I've seen built-in functions get mangled by
optimizations in the compiler. They can no longer be trusted when I'm
debugging code.

-- Martin K

2011\03\26@100056 by Xiaofan Chen

face picon face
On Fri, Mar 25, 2011 at 11:07 PM, Isaac Marino Bavaresco
<isaacbavarescospamspam_OUTyahoo.com.br> wrote:
> Interesting, this is THE PICLIST and my PIC post didn't receive any
> response yet, although there are several ongoing discussions under other
> tags.
>
> The PIC tag got just 2 messages in the last 36 hours.
>

You can always try Microchip forum which has many more PIC
related topics.

I do not use PIC24/dsPIC myself. But in the following Microchip forum
thread, I have collected many bootloaders related to PICs.
http://www.microchip.com/forums/m424874.aspx

This one seems to be quite good (written in assembly).
http://mrmackey.no-ip.org/elektronik/ds30loader/downloads.php

-- Xiaofa

2011\03\26@124709 by Harold Hallikainen

face
flavicon
face

> You can always try Microchip forum which has many more PIC
> related topics.
>
> I do not use PIC24/dsPIC myself. But in the following Microchip forum
> thread, I have collected many bootloaders related to PICs.
> http://www.microchip.com/forums/m424874.aspx
>
> This one seems to be quite good (written in assembly).
> http://mrmackey.no-ip.org/elektronik/ds30loader/downloads.php
>
> --
> Xiaofan

I had a look at ds30loader, but did not see a linker script, so it's
difficult to determine how memory is organized. In my PIC24H bootloaders,
I do the following:

0x0000 - goto code in boot section (under 0x200) that checks a switch or
whatever else is used to determine if we want to run application or
bootload.

Between 0x0000 and 0x0200 is bootloader code. All interrupt vectors point
to a jump table that starts above 0x0200.

0x0200 - goto application start. This includes stack initialization,
variable initialization, etc., as generated by PIC24 C compiler.

Right above 0x0200 is the interrupt jump table. The compiler can rewrite
this.

The bootloader is included in the application project. If I need to send
out code to be bootloaded in the field, I use file - export to export a
hex file that starts at 0x200.

If the bootloader uses a uart, the entire bootloader code is in the space
under 0x200. If the bootloader uses TCP, HTTP POST, or USB, the
application handles most of the work. It writes to SPI flash as a buffer.
When the copy to external flash is complete, the application calls a
function in the boot section (under 0x200) that copies the external flash
to internal flash, starting at 0x200. Because the application that was
used to load the new code is now being overwritten, there is a chance of
things going wrong leaving corrupt code in the application area so stuff
could not be reloaded. To deal with this problem, I keep a copy of the
factory installed code in external flash also. The user can hold down a
couple front panel buttons during power up to copy that factory code back
in to internal flash (starting at 0x200).

I've done  a similar thing with the PIC32, putting the boot stuff in the
boot flash of the PIC32.

Harold


-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2011\03\26@141912 by Isaac Marino Bavaresco

flavicon
face
Em 26/3/2011 13:46, Harold Hallikainen escreveu:
>> You can always try Microchip forum which has many more PIC
>> related topics.
>>
>> I do not use PIC24/dsPIC myself. But in the following Microchip forum
>> thread, I have collected many bootloaders related to PICs.
>> http://www.microchip.com/forums/m424874.aspx
>>
>> This one seems to be quite good (written in assembly).
>> mrmackey.no-ip.org/elektronik/ds30loader/downloads.php
>>
>> --
>> Xiaofan
> I had a look at ds30loader, but did not see a linker script, so it's
> difficult to determine how memory is organized.

Yes, a custom linker-script is essential for a boot-loader. You need to
ensure everything is allocated at known addresses that won't be moved at
each rebuild.


>  In my PIC24H bootloaders,
> I do the following:
>
> 0x0000 - goto code in boot section (under 0x200) that checks a switch or
> whatever else is used to determine if we want to run application or
> bootload.


Usually I leave for the application to decide when to invoke the
boot-loader. The external switch is kept just as a fail-safe mechanism
for when the application ceases responding.


> Between 0x0000 and 0x0200 is bootloader code. All interrupt vectors point
> to a jump table that starts above 0x0200.


I started using this approach but desisted after seeing the huge amount
of necessary hand-editing of the linker-script.


> 0x0200 - goto application start. This includes stack initialization,
> variable initialization, etc., as generated by PIC24 C compiler.
>
> Right above 0x0200 is the interrupt jump table. The compiler can rewrite
> this.


It would be good to reserve from 0x00000 up to 0x003ff for the
boot-loader, because each erase block is 512 instructions == 1k
addresses == 1536 bytes. The first erase block ends at 0x003ff.


The problem with this approach is that your applications must be adapted
to be boot-loaded. It must be linked in a way that it doesn't superposes
to the boot-loader areas.

I adopted and adapted the method of Microchip's TCP/IP boot-loader,
where the boot-loader resides in the very end of the FLASH and it
replaces the reset vector (goto instruction) of the application with its
own reset vector, keeping the original application's reset vector in a
separate area.
It is good because it allows any application (even old or built with
other compilers) to be boot-loaded, as long as it doesn't fill too much
the program memory and superposes the boot-loader itself.


> The bootloader is included in the application project. If I need to send
> out code to be bootloaded in the field, I use file - export to export a
> hex file that starts at 0x200.


But then you can only boot-load applications made for the boot-loader.


> If the bootloader uses a uart, the entire bootloader code is in the space
> under 0x200. If the bootloader uses TCP, HTTP POST, or USB, the
> application handles most of the work.


That the approach I am using now.


>  It writes to SPI flash as a buffer.


I use half of the internal FLASH.


{Quote hidden}

I do things differently, but the basic idea is similar.


> I've done  a similar thing with the PIC32, putting the boot stuff in the
> boot flash of the PIC32.
>
> Harold


Best regards,

Isaac

2011\03\26@144758 by Harold Hallikainen

face
flavicon
face
Thanks for the comments!


>
> Usually I leave for the application to decide when to invoke the
> boot-loader. The external switch is kept just as a fail-safe mechanism
> for when the application ceases responding.

I agree. On larger applications where a firmware update is possible over
USB, TCP, or HTTP POST, the update is handled entirely by the application.
The switch check is done in smaller bootloaders (like for 18 series) or as
a restore switch as discussed below.

{Quote hidden}

Yes, there was editing of the linker script (which seem to be lightly
commented and hard to read), but once it's done, it's done.

>
>> 0x0200 - goto application start. This includes stack initialization,
>> variable initialization, etc., as generated by PIC24 C compiler.
>>
>> Right above 0x0200 is the interrupt jump table. The compiler can rewrite
>> this.
>

I was incorrect on this address. The 0x200 is for my 18 series stuff. I
think it's 0x800 for PIC24.

>
> It would be good to reserve from 0x00000 up to 0x003ff for the
> boot-loader, because each erase block is 512 instructions == 1k
> addresses == 1536 bytes. The first erase block ends at 0x003ff.
>

Yes, as above, I was mistaken. It's 0x800.

>
> The problem with this approach is that your applications must be adapted
> to be boot-loaded. It must be linked in a way that it doesn't superposes
> to the boot-loader areas.
>

Yes, since the bootloader is included in the application project (and the
modified linker script), this is not an issue. The entire project MP3
environment is put in the production MP3 programmers.

> I adopted and adapted the method of Microchip's TCP/IP boot-loader,
> where the boot-loader resides in the very end of the FLASH and it
> replaces the reset vector (goto instruction) of the application with its
> own reset vector, keeping the original application's reset vector in a
> separate area.
> It is good because it allows any application (even old or built with
> other compilers) to be boot-loaded, as long as it doesn't fill too much
> the program memory and superposes the boot-loader itself.
>

I'm concerned about the bootloader being overwritten. Also, since the
application directly overwrites the reset and interrupt vector table, it
seems dangerous is something goes wrong.

>
>> The bootloader is included in the application project. If I need to send
>> out code to be bootloaded in the field, I use file - export to export a
>> hex file that starts at 0x200.
>
>
> But then you can only boot-load applications made for the boot-loader.
>

That's true. I don't expect other applications to be put into our product.


{Quote hidden}

Again, THANKS for the comments! There are certainly different ways of
doing things, and they are all valid.

Harold




-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2011\03\26@173055 by Isaac Marino Bavaresco

flavicon
face
Em 26/3/2011 15:47, Harold Hallikainen escreveu:

[snip]

{Quote hidden}

Not a problem for at least some devices. For the PIC24FJxxxGAxxx You can
write-protect a number of pages starting from the bottom or from the top
of the program memory.


>  Also, since the application directly overwrites the reset and interrupt vector table, it
> seems dangerous is something goes wrong.

The interrupt vector table is also a no-problem because the boot-loader
doesn't use it.

The only real problem is the reset vector, which must be erased and
re-programmed with the boot-loader's reset vector. There is a narrow
time window (some  units of ms) where problems may occur.

It's is a compromise solution: If you put your boot-loader at the bottom
of the memory, you waste memory and the interrupt latency grows (because
of the remapped interrupt vectors), and you can boot-load only specially
tailored applications. If you put your boot-loader at the top there is
the risk that a reset happens exactly when the reset-vector is erased (a
few milliseconds time window).


>>> The bootloader is included in the application project. If I need to send
>>> out code to be bootloaded in the field, I use file - export to export a
>>> hex file that starts at 0x200.
>>
>> But then you can only boot-load applications made for the boot-loader.
>>
> That's true. I don't expect other applications to be put into our product..


Because my client is using a different tool-chain and creating their own
application, I cannot make any assumptions about what they will boo-load.

[snip]

> Again, THANKS for the comments! There are certainly different ways of
> doing things, and they are all valid.
>
> Harold


I have used some of them already, and I found that there is no right
one, just that some are better for certain cases and other better for
other cases.


Best regards,

Isaac

2011\03\26@180649 by Dwayne Reid

flavicon
face
At 03:30 PM 3/26/2011, Isaac Marino Bavaresco wrote:
>Em 26/3/2011 15:47, Harold Hallikainen escreveu:
>
>It's is a compromise solution: If you put your boot-loader at the bottom
>of the memory, you waste memory and the interrupt latency grows (because
>of the remapped interrupt vectors), and you can boot-load only specially
>tailored applications. If you put your boot-loader at the top there is
>the risk that a reset happens exactly when the reset-vector is erased (a
>few milliseconds time window).

Can you add some protection to that write?  First write something to deal with a failed reset vector write at the beginning of wherever the reset vector is currently pointing to, then rewrite the reset vector, then restore what you changed back to what its supposed to be.

dwayne

-- Dwayne Reid   <@spam@dwaynerKILLspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2011\03\26@192401 by Isaac Marino Bavaresco

flavicon
face
Em 26/3/2011 19:06, Dwayne Reid escreveu:
> At 03:30 PM 3/26/2011, Isaac Marino Bavaresco wrote:
>> Em 26/3/2011 15:47, Harold Hallikainen escreveu:
>>
>> It's is a compromise solution: If you put your boot-loader at the bottom
>> of the memory, you waste memory and the interrupt latency grows (because
>> of the remapped interrupt vectors), and you can boot-load only specially
>> tailored applications. If you put your boot-loader at the top there is
>> the risk that a reset happens exactly when the reset-vector is erased (a
>> few milliseconds time window).
> Can you add some protection to that write?  First write something to
> deal with a failed reset vector write at the beginning of wherever
> the reset vector is currently pointing to, then rewrite the reset
> vector, then restore what you changed back to what its supposed to be.
>
> dwayne


Once I tried the following approach:

Knowing that 0xffffff = NOP, an erased FLASH page would be executed
through until the CPU reaches the begin of the next FLASH page.

Then by first erasing the second page and programming its first
instruction with a jump to the start of the code, when the first page is
erased it would be safe to reset the CPU.

*BUT* the PIC24/dsPIC core has a fail-safe mechanism that generates a
trap (kinda interrupt) if it tries to execute code inside the interrupt
vector area (starting at address 0x00004 and ending at 0x001ff). This
area is erased so all the vectors are pointing to 0xffffff, including
the trap that will be generated, resulting in very bad behavior.


Now, what I do is:

1) Copy the code that will be programmed to the first row to a RAM buffer
2) Patch its first instruction with the goto to the start of the
boot-loader.
3) Erase the first page (8 first rows).
4) Program the first row.
5) Program the remaining 7 rows.

The only risky point is between items 3 and 4, which lasts just some
milliseconds.


Best regards,

Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...