Strange byte order after Flash_Write_Row

[peini]

Sorry for my next question while trying to write a PIC32 bootloader.
I'am currently trying to do something very simple:

unsigned long bootAddressOffset = 0x20000;

memset( flashData, 0xFF, 2048 );
flashData[0] = 0x00;
flashData[1] = 0x01;
flashData[2] = 0x02;
flashData[3] = 0x03;
flashData[4] = 0x04;
flashData[5] = 0x05;
flashData[6] = 0x06;
flashData[7] = 0x07;
flashData[8] = 0x08;
flashData[9] = 0x09;
flashData[10] = 0x10;
flashData[11] = 0x11;
flashData[12] = 0x12;
flashData[13] = 0x13;
flashData[14] = 0x14;
flashData[15] = 0x15;

flashData[16] = 0x16;
flashData[17] = 0x17;
flashData[18] = 0x18;
flashData[19] = 0x19;

address = 0x1FC00000 + bootAddressOffset; // To be in the upper aliased boot area
Flash_Write_Row( address, flashData );

But if i read back the code with mikroProg i get this very strange byte order as you can see on the attached picture.
Does anyone have an idea why this is happening?
From where are the zeros comming?
Looks like it needs to be shifted left by 2 bytes.

Note: I've completely erased the PIC before.
Its a PIC32MZ2048ECH144.

[peini]

Ok, as so often, i've solved it by myself after a few hours of intense debugging
The problem was this line:

Code: Select all

unsigned char flashData[_FLASH_WRITE_LATCH];

which has to be

Code: Select all

unsigned long flashData[_FLASH_WRITE_LATCH / 4];

So the datatype unsigned long is very important here.

But now i have another problem:
Everything is written correctly except the configuration bytes.
I'am writing into the upper aliased boot panel.

The configuration bytes are:
DEVCFG3 : $1FC0FFC0 : 0x7B000000
DEVCFG2 : $1FC0FFC4 : 0xC0013112
DEVCFG1 : $1FC0FFC8 : 0x5F74C4B9
DEVCFG0 : $1FC0FFCC : 0x4000777B

And the hex file also contains:
1FC0FFC0: 7B000000 C0013112 5F74C4B9 4000777B

The first thing is the last character. The configuration is 7B but in mikroProg it reads as 7F.
BUT: If i program the code into the MCU via mikroProg and read back the code the configuration is a little bit different.
Does anyone know why?
And also WHO does write the alternative config registers at FF80? mikroProg or the MCU itself?

[stefan.filipovic]

Hi,

I'm glad that you have managed to solve previous issue on your own.

Regarding configuration bits, could you please zip and attach that hex file so I can reproduce the same behavior and investigate it?

Kind regards,