• AVR Freaks

Hot!EZBL _FOSC bits do not verify when porting to dsPIC33EP256MU810

New Member
  • Total Posts : 26
  • Reward points : 0
  • Joined: 2019/07/31 09:59:05
  • Location: 0
  • Status: offline
2019/08/20 17:32:12 (permalink)

EZBL _FOSC bits do not verify when porting to dsPIC33EP256MU810

Good evening,
I'm looking for some help in resolving a very minor issue which is preventing EZBL from working on custom hardware. I am using the example project designed for the dsPIC33EP512MU810 on the Explorer 16. On the hardware that the project was designed for, the bootloader works great on the Explorer board with the 512MB variant. On the custom hardware which has the 256MB variant, the bootloader fails on a "read-back verification failure". On debugging, it seems to be at least one or both of _FOSCSEL and _FOSC. These are programmed to use the internal oscillator currently so the programming is identical between the custom hardware and the Explorer board. The only difference is the processor that the project is built with. 
To switch between the processors, I am just going into the project properties and changing the target to the dsPIC33EP256MU810. I am also rebuilding the example project and verifying the .gld and .S files are updated accordingly after the processor has been changed. Is there anything else that I need to do? From what I saw in the debugging struct via the PicKit 4, it seems that the 'reserved' bits in the FOSC / FOSCSEL registers which per the datasheet are supposed to read as '0' are reading back as a '1' in the application. It seems like the 256MB variant doesn't know these bits are 'reserved' and doesn't mask them properly.  For example, in the .S file of the example project there is this line:
; Bootloader code block intended for program region 'FOSCSEL'
; 0xF80006 to 0xF80008, length 0x000002 (3 bytes; needs 0 pages)
.pushsection EZBL_BTLDR_CONFIG_WORD_FOSCSEL, address(0xF80006), code, keep
.pword 0x00001 /* 0xF80006 ... */
However, when the code reads the physical address, it fails the compare because it is comparing the '1' from the hex file to a '0x79' from the device.
Thanks in advance.
post edited by kparrent - 2019/08/20 17:33:31

0 Replies Related Threads

    Jump to:
    © 2020 APG vNext Commercial Version 4.5