| View previous topic :: View next topic |
| Author |
Message |
bennyboos
Joined: 17 Nov 2005
Posts: 30
Location: Chester UK
|
| CORE-E0004: Trap due to unimplemented flash |
 Posted: Tue Feb 24, 2015 4:31 am |
 |
|
Heeeelp ?
I have been experimenting with 16bit devices (dsPIC30F3013) and am really struggling with debugging it via an ICD3 in MPLAB V8.90. The chip keeps resetting for no obvious reason.
I tried stepping through the disassembly listing and found that the chip resets when it tries to execute | Code: | | tblrdh.w [0x0006],0x0000 |
I then tried using MPLAB SIM and it threw up this error CORE-E0004: Trap due to unimplemented FLASH memory access, occurred from instruction at 0x000118 I have no idea why but is this a fault with the compiler ?
I'm happy to post the source code - it doesn't do anything more exotic so far than display a simple message to an HCMS2973 LED matrix.
During fiddling I also encountered an "CORE-W0001: Illegal operand" which is really shaking my faith with my PCWH compiler. (Though I have not as yet been able to replicate this latter fault?). |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19327
|
|
| Posted: Tue Feb 24, 2015 8:31 am |
|
|
Look at the code that generates the line. If you look at the .lst file it's just above the assembly.
It looks like you are doing perhaps a pointer/array access, and trying to talk to the wrong memory address. On a PIC18, this will still run, and just give invalid results. On the PIC24/PIC33, you will get an address error trap (which by default will reset the chip). |
|
|
bennyboos
Joined: 17 Nov 2005
Posts: 30
Location: Chester UK
|
|
| Posted: Tue Feb 24, 2015 8:43 am |
|
|
Here is the disassembly listing.
MPLAB-SIM reports that the error is at instruction 0118
At this point, it doesn't seem to relate directly to any of my code
(Instead coming under the generic #device line)
I do do some array accessing, but this same code worked perfectly on an 8bit device and all I have done is change the output pins to correspond to the sPIC24 device ?
| Code: | --- W:\Shared Slide-dropper Folder\Densitometer\PIC_Code\dsPIC30F3013\main.c -------------------
1: // Blah de blah - starting point for dsPIC30F3013 chip based densitometer
0000 0403E4 goto 0x0003e4
2: #case // make compiler case sensitive (necessary for all the SFR names)
3: #device DSPIC30F3013
0100 EF2032 clr.w 0x0032
0102 2017A3 mov.w #0x17a,0x0006
0104 500183 sub.w 0x0000,0x0006,0x0006
0106 310005 bra c, 0x000112
0108 2011C3 mov.w #0x11c,0x0006
010A 418000 add.w 0x0006,0x0000,0x0000
010C BA4010 tblrdl.b [0x0000],0x0000
010E EF6001 clr.b 0x0001
0110 060000 return
0112 2011C0 mov.w #0x11c,0x0000
0114 418183 add.w 0x0006,0x0006,0x0006
0116 418180 add.w 0x0006,0x0000,0x0006
0118 BA8013 tblrdh.w [0x0006],0x0000
011A 060000 return
011C 440000 add.w 0x0010,0x0000,0x0000 |
|
|
|
bennyboos
Joined: 17 Nov 2005
Posts: 30
Location: Chester UK
|
|
| Posted: Tue Feb 24, 2015 9:48 am |
|
|
Thanks Jeremiah (& Ttelmah)
I just stepped through everything very slowly and carefully and did indeed find an "out of range" indice into an array 
I guess I never noticed this before as it only occurred for a particular character that I don't think I had ever tried displaying before.
Thanks both of you for your help.
Ben  |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19327
|
|
| Posted: Tue Feb 24, 2015 12:30 pm |
|
|
As a comment, if you search here, you will find example code for how to add interrupt code to trap the error interrupt, stop, and allow you to see what address the actual code fails at. Beware the offset used inside the interrupt has to change with V5. Great thing with this added, is you don't have to step through, but can 'autodetect' where the code fails. Could save time in the future.  |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
