| View previous topic :: View next topic |
| Author |
Message |
Zer0flag
Guest
|
| Be careful with EBTR table read protection |
 Posted: Thu Jan 03, 2008 8:15 am |
 |
|
Hi all!
I had a very annoying problem on a PIC18 with constant strings which started disappearing when my program grew and when I moved the functions around the program. I thought it was a compiler bug but then I noticed that I had enabled a table read protection for program memory through #fuses EBTR (Table-read-protect MEMORY from table-reads executed in other blocks). For reading constant strings the compiler seems to use such table reads and setting NOEBTR seems to solve my problem. So be careful when setting these!
BTW: Can anyone tell me what the table reads protection is good for?
Best regards,
Zer0flag |
|
 |
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Thu Jan 03, 2008 9:29 am |
|
|
spec 18F452 pg 209
| Quote: | The user program memory is divided into five blocks.
One of these is a boot block of 512 bytes. The remainder
of the memory is divided into four blocks on binary
boundaries. |
so if you have boot programmer, and the protection bit
you can't read from one section and then over into the next.
| Quote: | 19.4 Table Read instruction that
executes from within that block is allowed to read. A
Table Read instruction that executes from a location
outside of that block is not allowed to read, and will
result in reading ‘0’s. |
so the boot programmer can only read in its area, and trying to read
outside the boot area in the next data table will read back 0.
maybe helpfull, maybe not,.. ? |
|
|
Zer0flag
Guest
|
|
| Posted: Thu Jan 03, 2008 2:43 pm |
|
|
| Thank you treitmey! So if I understood correctly it is a kind of code protection. The problem is that the datasheets tell us what we can do but never why this is useful :( |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
