Hello i'm currently developing some new commands that send some considerable amount of data, and just perceived something.

If I send a message with a payload that can fit in one message, I receive the callback correctly. When the payload grows a bit and fragmentation is needed, no callback is received. This worries me because it can.

• Fill the unicast table without emptying it.
• Lose some control of messages sent correctly or not.

Emberznet 6.9.1.0 stack,

efr32mg21b020f512

Test something like this and change the payload.

void dummyData(void)
{
  logPrint(LOG_DEBUG, "Sending dummy data");
  uint8_t buff[5] = {0x01,0x4B,0x41,0x1,0x4B};
  emberAfFillCommandGlobalServerToClientReportAttributes(0x4B4B,buff,5);
  emberAfSetCommandEndpoints(10, 1);
  emberAfSendCommandUnicastWithCallback(EMBER_OUTGOING_DIRECT, 0x0000, msgCallback);
}

void msgCallback (EmberOutgoingMessageType type,
    uint16_t indexOrDestination,
    EmberApsFrame *apsFrame,
    uint16_t msgLen,
    uint8_t *message,
    EmberStatus status){
  emberAfCorePrint("Callback of sent message %X",status);

}

Hello i'm currently developing some new commands that send some considerable amount of data, and just perceived something.

If I send a message with a payload that can fit in one message, I receive the callback correctly. When the payload grows a bit and fragmentation is needed, no callback is received. This worries me because it can.

• Fill the unicast table without emptying it.
• Lose some control of messages sent correctly or not.

Emberznet 6.9.1.0 stack,

efr32mg21b020f512

Test something like this and change the payload.

void dummyData(void)
{
  logPrint(LOG_DEBUG, "Sending dummy data");
  uint8_t buff[5] = {0x01,0x4B,0x41,0x1,0x4B};
  emberAfFillCommandGlobalServerToClientReportAttributes(0x4B4B,buff,5);
  emberAfSetCommandEndpoints(10, 1);
  emberAfSendCommandUnicastWithCallback(EMBER_OUTGOING_DIRECT, 0x0000, msgCallback);
}

void msgCallback (EmberOutgoingMessageType type,
    uint16_t indexOrDestination,
    EmberApsFrame *apsFrame,
    uint16_t msgLen,
    uint8_t *message,
    EmberStatus status){
  emberAfCorePrint("Callback of sent message %X",status);

}

You will se that with big payloads fragmentation will occour and no callback will ever be received...

Hi @Patrik I will scalate this issue to a support ticket, is becoming a big problem in our client networks, I will create a testing scenario where we can observe this, but YES the router parent puts its own short id into network layer source address, causing data to be misinterpreted and router data is the sleepy end device is overriding it, some cases no information arriving.

Already tried updating my devices to the latests 6.7.8 SDK and could not get it to work, we a have a big limitation that the concentrator NPC can not be updated remotely and changing it will change the z3gateway software, we need a solution for this.

Solved. Even though I am using only 3 pages of flash I need to use 4 pages of flash after storage when using application bootloader

Currently working this way

• EFR32MG21
• Application bootloader (tokens end of flash)
• 3 pages of NVM3 (but using 4 flashes of space?)
• Single image bootloader with the corresponding space
• 248kb app storage with this conditions
  • OTA storage start offset : 270336 (248kb app)
  • OTA storage endoffset : 491520 (216kb storage)
  • NVM3 plugin with 3 flash pages
  • 16kb single image bootloader configured the same way with LZ4.

A little more space on 512kb devices for firmware :)

Solved. Even though I am using only 3 pages of flash I need to use 4 pages of flash after storage when using application bootloader

Currently working this way

• EFR32MG21
• Application bootloader (tokens end of flash)
• 3 pages of NVM3 (but using 4 flashes of space?)
• Single image bootloader with the corresponding space
• 248kb app storage with this conditions
  • OTA storage start offset : 270336 (248kb app)
  • OTA storage endoffset : 491520 (216kb storage)
  • NVM3 plugin with 3 flash pages
  • 16kb single image bootloader configured the same way with LZ4.

A little more space on 512kb devices for firmware :)

Solved. Even though I am using only 3 pages of flash I need to reserve 4 pages of flash after storage when using application bootloader

Currently working this way

• EFR32MG21
• Application bootloader (tokens end of flash)
• 3 pages of NVM3 (but using 4 flashes of space?)
• Single image bootloader with the corresponding space
• 248kb app storage with this conditions
  • OTA storage start offset : 270336 (248kb app)
  • OTA storage endoffset : 491520 (216kb storage)
  • NVM3 plugin with 3 flash pages
  • 16kb single image bootloader configured the same way with LZ4.

A little more space on 512kb devices for firmware :)

Query next image response: New image is available for download.
Starting download, Version 0x00000023
Bootload state: Downloading Image
Starting erase from offset 0x00042000 to 0x0007A000
EEPROM Erase complete
EMBER_NETWORK_UP 20dBm

This is what happens, starts erasing memory and my devices goes nuts,thes EMBER_NETWORK_UP Is a callback from other function, when I check reporting table all data is  garbaged and damaged.

it erases up to address 0x7A000 (488kb) and I have 3 flash pages (24) that should start from 488kb to 512kb, but why my data is being corrupted, I have some problem like that on trying to update on emberznet 6.5 or 6.4 dont remember, i am using emberznet 6.9.0.0 to do this....

Hello, I am using a EFR32MG21B020F152 and i am trying to create a firmware where I have this memory structure

0x00000 - Start of bootloader
0x04000 - End of bootloader (start of application)
0x40000 - End of application (Start of tokens
0x46000 - End of token (start of storage)
0x7E000 - End of storage

I am trying to use 240kb of firmware space with 224kb of storage space so I can use LZ4 compression and gain some space when doing zigbee OTAs

Currently I cannot make this work. When I set bootloader to local storage, the linker tries to use half of flash and not the size I want, i tried setting INTERNAL_STORAGE_SIZE but no luck.

Also tried setting application bootloader but when looking at .map output the compiler my 239kb firmware occupies a bit more space for symbols and stuff, and when starting the ota process where it erases the flash space the program starts to crash and have undefined behaviour.

all firmware tries where made with a corresponding bootloader firmware using the same slot spaces

i will try more options but I will accept some help or shed some light if I am doing something wrong.