• AVR Freaks

Helpful ReplyHot!Unable to upload firmware with EZBL on dsPIC33FJ128GP804

Author
Addy
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2019/08/28 14:24:05
  • Location: 0
  • Status: offline
2019/08/29 14:22:17 (permalink)
0

Unable to upload firmware with EZBL on dsPIC33FJ128GP804

Hello. I have a custom board using a DSPIC33FJ128GP804 microcontroller. On a previous iteration of this board I was using EZBL successfully, though it was something like v1.05 as I had set that up back in 2016. For the current iteration I updated MPLAB to v5.25 with xc16 v1.40. When I tried to use the old bootloader code I ran into compile errors, so I decided to switch to the latest version of EZBL, v2.11.
 
I have been working through the examples in "EZBL Hands-on Bootloading Exercises". My goal is to get ex_boot_uart working. I created my own "Hardware Initializer" file for my board based on one of the example files. I had to customize the UART pin mapping for my board as well as the LED output. I added my EZBL_SET_CONF statements to set up the device configuration fuses, to set up the oscillator properly for my board and so on.
 
With the proper hardware initializer file and following the instructions in the bootloading exercises document, I am able to flash ex_boot_uart with my PICkit 3. The board appears to be working correctly. The bootloader LED flashes at 8Hz when the board powers up and continues to flash because there is no application on the mcu yet.
 
The next part of the bootloading exercises is "Loading an example application". I followed the instructions in this section to set up the ex_app_led_blink project. When I click "Clean & Build" the build process goes smoothly until it's time to send the app to the bootloader via UART. I get an error, Timeout reading from 'COM5'.
 
Here's the log:
ezbl_integration\ezbl_comm.exe -artifact=dist/uart/production/ex_app_led_blink.production.bl2 -com=COM5 -baud=230400 -slave_address=0x00 -timeout=100 -log=C:\Users\Adam\AppData\Local\Temp\ezbl_comm_log.txt 

 0.032651: TX 64 @ 0:
    55 55 55 55 55 55 55 55 4D 43 55 50 48 43 4D 45 UUUUUUUUMCUPHCME
    42 4C 32 42 8E 27 00 00 16 F6 E9 D3 B1 CE 61 DD BL2B.'........a.
    34 E5 68 8D 6B 5B 5B D0 4C 14 00 00 0A 00 02 00 4.h.k[[.L.......
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 0.052388: RX 2 @ 0:
    13 FF ..
 0.052399: RX 2 @ 2:
    13 FF ..
 0.068368: RX 2 @ 4:
    13 FF ..
 0.068380: RX 2 @ 6:
    13 FF ..
 0.084336: RX 2 @ 8:
    13 FF ..
 0.084348: RX 2 @ 10:
    13 FF ..
 0.084355: RX 2 @ 12:
    13 FF ..
 0.100307: RX 2 @ 14:
    13 FF ..
 0.100316: RX 2 @ 16:
    13 FF ..
 0.116287: RX 2 @ 18:
    13 FF ..
 0.116302: RX 2 @ 20:
    13 FF ..

 0.218051: Timeout reading from 'COM5'

 
ezbl_comm sends 64 bytes to the microcontroller. After some time, the microcontroller responds with 0x13FF, repeating itself about 10 times before going silent. I've checked the UART signals with an oscilloscope and logic analyzer. The baud rates are correct and the logic analyzer decodes the UART signals properly. I've tried using different baud rates, with and without auto-baud detection, but the behavior is always the same. I've tried increasing the timeout to 5000, same results. 
 
I searched on google and on these forums for any clues as to what's going on here. This snippet was interesting:
The bytes sent back to PC by microcontroller are software flow control advertisements. Since EZBL implements a file oriented Bootloader, not a command-response protocol managed by the PC, there is a need to throttle the PC transfer of the firmware image. Otherwise, the PC would send data at the full line rate, and while the Bootloader is busy programming and checking the prior data, an overflow will occur as more data arrives than can be buffered in the RAM RX FIFO.

Each flow control advertisement consists of a 16-bit, little-endian signed integer. Negative numbers mean "halt all transfer and wait", while positive numbers mean "I have n number of bytes of free space available in my RAM RX FIFO". 0x0000 is reserved to mean "I am terminating this bootload session and the next 16-bit number I send you is a courtesy status code."

 
If there's any documentation out there describing what these 16-bit codes are, I could find out what 0x13FF corresponds to and hopefully be pointed in the right direction. I've searched through the ezbl source files but I haven't found anything relevant to this problem yet. Any advice would be greatly appreciated. 
#1
Addy
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2019/08/28 14:24:05
  • Location: 0
  • Status: offline
Re: Unable to upload firmware with EZBL on dsPIC33FJ128GP804 2019/08/30 14:00:09 (permalink)
0
When debugging with my PICkit 3, if I watch the EZBL_bootCtx.state variable I can see that it's 0 normally (SM_SYNC_INIT) when the bootloader is idle. When I try to upload firmware with ezbl_comm.exe, the state changes to 2 (SM_ERASE) and the microcontroller loses connection with the debugger. At this point the bootloader doesn't seem to be working anymore. The LED no longer flashes and there is no response at all if I try to upload the firmware again. Resetting the power supply doesn't help. I have to flash the bootloader with the PICkit to make it work again.
 
I monitored the 3.3V power rail while replicating the firmware upload problem. The power looks fine, it doesn't drop at all when I try to upload firmware. 
#2
gbarry
New Member
  • Total Posts : 9
  • Reward points : 0
  • Joined: 2014/01/30 22:21:04
  • Location: 0
  • Status: offline
Re: Unable to upload firmware with EZBL on dsPIC33FJ128GP804 2019/08/31 16:13:02 (permalink) ☄ Helpfulby Addy 2019/09/03 10:06:02
0
It's been a year and a half since messing with EZBL.  One thing I remember is that the error codes aren't all in one place.  So just because your code's not listed doesn't mean you've found the list.  I found this one in ezbl.h :
 
#define EZBL_ERROR_RESERVED_XOFF_NEG (-237) // 0xFF13 Bootloader page erase sequence busy/keep alive code (not generated as final status code). NOTE: 0x13 is the XOFF character, so if the remote hardware supports XOFF/XON software flow control, the remote node should halt its transmit stream until the bootloader erase sequence is complete.
 
That should enable you to search it out wherever it's located.
 
It sort of looks like the chip goes away when it's being erased.  Partial erases take time since they are a block at a time.  I seem to recall that once you finally convince the bootloader that you are a real host with a real file, it immediately goes off and erases the chip.  Also note that if you change parts (even a little) the write and erase schemes can change in surprising ways.  Though hopefully you're able to use their erase function without having to modify it and it should know what to do.
 
Good Luck!
#3
Addy
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2019/08/28 14:24:05
  • Location: 0
  • Status: offline
Re: Unable to upload firmware with EZBL on dsPIC33FJ128GP804 2019/09/05 14:38:36 (permalink)
0
Thanks for the insight @gbarry. It's more clear now what is happening, though I still don't know why. 
 
I spent some time wiring up another TTL-USB adapter to my board on a couple of spare IO lines. In my hardware initializer file I configured my UARTs so that the original one is for bootloader communication and the second UART is used as stdio. I was hoping to eventually enable verbose mode in the ezbl library so I could get more information about what's going on.
 
I started by using EZBL_printf() to print a test message, in the ex_boot_uart code after the board initialization is finished. Unfortunately the output I get is gibberish, with some pulses of 60-70ns which are much faster than the baud rate I had specified. I checked my pin configurations but I couldn't find any issues. The first UART still responds as described in my original post when I try to upload the app firmware.
 
To make sure my microcontroller wasn't somehow damaged, I went back to MPLAB v3.00 with my old copy of EZBL v1.01. I was able to get ex_boot_uart working and I am able to upload my own firmware:
 
Connected: DEVID, DEVREV: 0000062F, 00003004; Buffering: 96 bytes
Erase.........
Upload progress: |0% 25% 50% 75% 100%|
|..................................................|
22245 bytes sent in 6.327s (3516 bytes/second)
 
Seems like the microcontroller works fine. At this point I think there could be a bug in the EZBL library. I've spent too much time trying to get the new version of the bootloader working, so I'm going to stick with EZBL v1.01 for now and continue working on my firmware. 
#4
antoniovazquezblanco
New Member
  • Total Posts : 10
  • Reward points : 0
  • Joined: 2019/01/30 04:11:09
  • Location: 0
  • Status: offline
Re: Unable to upload firmware with EZBL on dsPIC33FJ128GP804 2019/12/03 09:29:30 (permalink)
0
I seem to have the same issue as described above. I've updated from EZBL v2.04 to v2.11 and now I am unable to update my dsPIC33FJ64GP306A. After checking that this is not hardware related I've enabled various debug flags in ezbl_lib and tryed to perform an update.

Install2Flash debug:

  Found BL2B header
  BOOTID_HASH offered: 7D508C2FF3300562F24822C1270B5C8E
                 ours: 7D508C2FF3300562F24822C1270B5C8E
  APPID_VER: offered = 0.00.0000
             ours    = 65535.65535.4294967295 (no App present)
  Accepting offered firmware update: size = 55747
  Erasing....

 
EraseAppSpace debug:

0x002400  blank checking: blank
0x002800  blank checking: blank
0x002C00  blank checking: blank
0x003000  blank checking: blank
0x003400  blank checking: blank
0x003800  blank checking: blank
0x003C00  blank checking: blank
0x004000  blank checking: blank
0x004400  blank checking: blank
0x004800  blank checking: blank
0x004C00  blank checking: blank
0x005000  blank checking: blank
0x005400  blank checking: blank
0x005800  blank checking: blank
0x005C00  blank checking: blank
0x006000  blank checking: blank
0x006400  blank checking: blank
0x006800  blank checking: blank
0x006C00  blank checking: blank
0x007000  blank checking: blank
0x007400  blank checking: blank
0x007800  blank checking: blank
0x007C00  blank checking: blank
0x008000  blank checking: blank
0x008400  blank checking: blank
0x008800  blank checking: blank
0x008C00  blank checking: blank
0x009000  blank checking: blank
0x009400  blank checking: blank
0x009800  blank checking: blank
0x009C00  blank checking: blank
0x00A000  blank checking: blank
0x00A400  blank checking: blank
0x00A800  blank checking: blank
0xF80010  bl

 
Given that last line, it seems that the bootloader is trying to check if page located at 0xF80010 is blank or not. The following link shows memory organization of my device (which BTW seems to have an errata): http://ww1.microchip.com/downloads/en/DeviceDoc/70593d.pdf#G5.1052707
 
The page the bootloader is trying to check just before crashing seems to be reserved memory.
 
I will try to further debug the issue but it would be nice if Microchip gave some support here...
#5
antoniovazquezblanco
New Member
  • Total Posts : 10
  • Reward points : 0
  • Joined: 2019/01/30 04:11:09
  • Location: 0
  • Status: offline
Re: Unable to upload firmware with EZBL on dsPIC33FJ128GP804 2019/12/03 09:47:40 (permalink)
0
I have modified EZBL_EraseAppSpace to allow me to further debug the code without the log being cut. This is my modified code from line 113 onwards:

        EZBL_printf("\n0x%06lX", limits.u32[0]);
        if(!EZBL_IsPageErased(limits.u32[0])) // Don't waste time or endurance if the page is already blank
        {
            if(EZBL_IsEraseRestricted(limits.u32[0]))  // Don't erase this address if it is in the .text.EZBLNoEraseRanges section, such as user pages reserved for emulated data EEPROM
            {
                EZBL_printf("s");
                continue;
            }
            EZBL_printf("e");
            
            // Wait 3 ms
            NOW_Wait(3u*NOW_ms);
            
            EZBL_NVMKey = keySave - (0xFC21u - 0x03DFu);
            EZBL_ErasePage(limits.u32[0]);
            EZBL_RestoreAppErasable(0);         // If we've erased some flash Config words, restore their default values
            return 1;
        }
#if defined(EZBL_DEBUG)
        else
            EZBL_printf("b");
#endif

 
The code above produces the following output:


0x002400b
0x002800b
0x002C00b
0x003000b
0x003400b
0x003800b
0x003C00b
0x004000b
0x004400b
0x004800b
0x004C00b
0x005000b
0x005400b
0x005800b
0x005C00b
0x006000b
0x006400b
0x006800b
0x006C00b
0x007000b
0x007400b
0x007800b
0x007C00b
0x008000b
0x008400b
0x008800b
0x008C00b
0x009000b
0x009400b
0x009800b
0x009C00b
0x00A000b
0x00A400b
0x00A800b
0xF80010e

 
Which means that the bootloader is trying to erase memory located at 0xF80010 that is indeed reserved.
 
Anyone that knows this code and that can help fix the issue?
 
Thanks!
 
#6
Stampede
Super Member
  • Total Posts : 403
  • Reward points : 0
  • Joined: 2006/10/04 05:59:28
  • Location: Germany
  • Status: offline
Re: Unable to upload firmware with EZBL on dsPIC33FJ128GP804 2019/12/04 03:52:30 (permalink)
1 (1)
If the memory is reserved, it must be made public to the EZBL. THis is done by the ezbl.jar tool by writing the erase / non-erase areas into the flash and pushing the sections into the linker.
Thus, are those ranges correctly placed into your bootloader code?
#7
antoniovazquezblanco
New Member
  • Total Posts : 10
  • Reward points : 0
  • Joined: 2019/01/30 04:11:09
  • Location: 0
  • Status: offline
Re: Unable to upload firmware with EZBL on dsPIC33FJ128GP804 2019/12/04 04:11:46 (permalink)
5 (1)
It seems I was wrong. The problem is not that 0xF80010 is a reserved memory area.
 
Here we have the code for the EraseAppSpace function:

int EZBL_EraseAppSpace(unsigned int *eraseState)
{
    EZBL_UNION_64 limits;
    unsigned long endLimitAddr;
    unsigned long tblRdPtr;
    unsigned int i;
    unsigned int blankRepeats = 8u;
    unsigned short keySave;
#if defined(__XC16__)
    const unsigned int pageAddrSize = EZBL_SYM(EZBL_ADDRESSES_PER_SECTOR);
#elif defined(__XC32__) || defined(__PIC32__)
    const unsigned int pageAddrSize = 0x800u;
#endif

    keySave = EZBL_NVMKey;
    EZBL_NVMKey = 0;

    // Create a dummy 0 item section in case if there are no sections named .text.EZBLAppSpaceGeometry. This takes no space.
    __asm__("\n    .pushsection    .text.EZBLAppSpaceGeometry, code, keep" EZBL_PAGE_ATTR
            "\n    .popsection");

    tblRdPtr = (unsigned long)__builtin_section_begin(".text.EZBLAppSpaceGeometry");
    limits.u64 = EZBL_ReadTablePair(&tblRdPtr);
    i = 0;
    do
    {
        // Find the erase page address
        for(; i < *eraseState; i++)
        {
            if(limits.u8[2] >= 0xF8u)
            {
                EZBL_printf("\n    Reached Config bytes @ 0x%06lX, restoring and calling EZBL_EraseAppSpace() finished\n\n", limits.u32[0]);
                EZBL_RestoreAppErasable(1);
                return 0;
            }

            endLimitAddr = limits.u32[1];
            if(limits.u16[2] & (pageAddrSize-1u))
                endLimitAddr = (endLimitAddr | (pageAddrSize-1u))+1u;
            limits.u32[0] += pageAddrSize;
            if(limits.u32[0] >= endLimitAddr)        // Is start address + x*pageSize past the EZBLAppSpaceGeometry end address?
            {
                if(((unsigned int)tblRdPtr) >= (unsigned int)__builtin_section_end(".text.EZBLAppSpaceGeometry"))
                {
                    EZBL_printf("\n    All done erasing pages. Last tested address = 0x%06lX\n\n", limits.u32[0] - pageAddrSize);
                    return 0;
                }
                limits.u64 = EZBL_ReadTablePair(&tblRdPtr); // Increment to next EZBLAppSpaceGeometry
                if(limits.u32[0] < endLimitAddr)            // Still on the same erase page?
                    i--;
            }
        }
        *eraseState += 1u;

        EZBL_printf("\n0x%06lX  blank checking", limits.u32[0]);
        if(!EZBL_IsPageErased(limits.u32[0])) // Don't waste time or endurance if the page is already blank
        {
            if(EZBL_IsEraseRestricted(limits.u32[0]))  // Don't erase this address if it is in the .text.EZBLNoEraseRanges section, such as user pages reserved for emulated data EEPROM
            {
                EZBL_printf(": erase restricted; skipping");
                continue;
            }
            EZBL_printf(": not blank; erasing");
            EZBL_NVMKey = keySave - (0xFC21u - 0x03DFu);
            EZBL_ErasePage(limits.u32[0]);
            EZBL_RestoreAppErasable(0);         // If we've erased some flash Config words, restore their default values
            return 1;
        }
#if defined(EZBL_DEBUG)
        else
            EZBL_printf(": blank");
#endif
    } while(--blankRepeats);

    return 1;
}

 
The limits variable is updated in two places, one before the do-while loop and the other is at the end of the for loop.
It seems to me that limits gets updated inside the for loop and continues to the erase statement without checking if
limits.u8[2] >= 0xF8u

as it is done at the begining of the while loop. This causes the bootloader to erase the configuration bits of my device, leaving it unusable.
 
The implementation of this function in EZBL v2.04 was much more easy to read and allways performs the check above before erasing the memory:

int EZBL_EraseAppSpace(unsigned int *eraseState)
{
    EZBL_UNION_64 rd;
    unsigned long rdAddr;
    unsigned int tableAddrSize;
    unsigned int pageNum;

    rdAddr        = __builtin_section_begin(".text.EZBLAppSpaceGeometry");
    tableAddrSize = __builtin_section_size(".text.EZBLAppSpaceGeometry");

    EZBL_printf("\n    .text.EZBLAppSpaceGeometry stored at: [%06lX, %06lX)", rdAddr, rdAddr + tableAddrSize);

    pageNum = 0;
    while(tableAddrSize)
    {
        EZBL_printf("\n    Table value read from %06lX: ", rdAddr);
        rd.u64 = EZBL_ReadTablePair(&rdAddr);
        EZBL_printf("%06lX, %06lX", rd.u32[0], rd.u32[1]);
        tableAddrSize -= 0x4;
        while(rd.u32[0] < rd.u32[1])
        {
            pageNum++;

            if(pageNum > *eraseState)
            {
                *eraseState = pageNum;
                if(!EZBL_IsEraseRestricted(rd.u32[0]))  // Don't erase this address if it is in the .text.EZBLNoEraseRanges section, such as user pages reserved for emulated data EEPROM
                {
                    EZBL_printf("\n    %06lX not erase restricted", rd.data[0]);
                    if(rd.u8[2] >= 0xF8u)               // If we've hit some non-volatile Config bytes, restore their default values and call ourselves done
                    {
                        EZBL_RestoreAppErasable(1);
                        return 1;
                    }
                    else if(!EZBL_IsPageErased(rd.u32[0]))
                    {
                        EZBL_printf("\n    %06lX not erased, going to erase", rd.u32[0]);
                        EZBL_FIFOFlush(EZBL_STDOUT, (unsigned long)-1);
                        // Erase the page (clears EZBL_NVMKey on return)
                        EZBL_NVMKey += 0x03DF - 0xFC21;
                        EZBL_ErasePage(rd.u32[0]);
                        EZBL_printf("\n    %06lX erase done, now calling EZBL_RestoreAppErasable(0);", rd.u32[0]);
                        EZBL_FIFOFlush(EZBL_STDOUT, (unsigned long)-1);
                        EZBL_RestoreAppErasable(0);
                        EZBL_printf("\n    EZBL_RestoreAppErasable(0) complete");
                        EZBL_FIFOFlush(EZBL_STDOUT, (unsigned long)-1);
                        return 1;
                    }
                    EZBL_printf(", but is already erased");
                }
            }
            rd.u32[0] += EZBL_SYM(EZBL_ADDRESSES_PER_SECTOR);
        }
    }

    EZBL_printf("\n    All done erasing pages");
    EZBL_FIFOFlush(EZBL_STDOUT, (unsigned long)-1);
    // No more erasable pages found, do nothing and return end of enum code
    EZBL_NVMKey = 0x0000;
    return 0;
}

 
 
#8
antoniovazquezblanco
New Member
  • Total Posts : 10
  • Reward points : 0
  • Joined: 2019/01/30 04:11:09
  • Location: 0
  • Status: offline
Re: Unable to upload firmware with EZBL on dsPIC33FJ128GP804 2019/12/04 08:54:26 (permalink)
0
I can verify that if you completely substitute EZBL_EraseAppSpace implementation of version v2.11 with the implementation of v2.04 the bootloader works as expected again.
 
I can also verify that if an address check is added before the erase procedure as in the following code, the issue is solved for me:

int EZBL_EraseAppSpace(unsigned int *eraseState)
{
    EZBL_UNION_64 limits;
    unsigned long endLimitAddr;
    unsigned long tblRdPtr;
    unsigned int i;
    unsigned int blankRepeats = 8u;
    unsigned short keySave;
#if defined(__XC16__)
    const unsigned int pageAddrSize = EZBL_SYM(EZBL_ADDRESSES_PER_SECTOR);
#elif defined(__XC32__) || defined(__PIC32__)
    const unsigned int pageAddrSize = 0x800u;
#endif

    keySave = EZBL_NVMKey;
    EZBL_NVMKey = 0;

    // Create a dummy 0 item section in case if there are no sections named .text.EZBLAppSpaceGeometry. This takes no space.
    __asm__("\n    .pushsection    .text.EZBLAppSpaceGeometry, code, keep" EZBL_PAGE_ATTR
            "\n    .popsection");

    tblRdPtr = (unsigned long)__builtin_section_begin(".text.EZBLAppSpaceGeometry");
    limits.u64 = EZBL_ReadTablePair(&tblRdPtr);
    i = 0;
    do
    {
        // Find the erase page address
        for(; i < *eraseState; i++)
        {
            if(limits.u8[2] >= 0xF8u)
            {
                EZBL_printf("\n    Reached Config bytes @ 0x%06lX, restoring and calling EZBL_EraseAppSpace() finished\n\n", limits.u32[0]);
                EZBL_RestoreAppErasable(1);
                return 0;
            }

            endLimitAddr = limits.u32[1];
            if(limits.u16[2] & (pageAddrSize-1u))
                endLimitAddr = (endLimitAddr | (pageAddrSize-1u))+1u;
            limits.u32[0] += pageAddrSize;
            if(limits.u32[0] >= endLimitAddr)        // Is start address + x*pageSize past the EZBLAppSpaceGeometry end address?
            {
                if(((unsigned int)tblRdPtr) >= (unsigned int)__builtin_section_end(".text.EZBLAppSpaceGeometry"))
                {
                    EZBL_printf("\n    All done erasing pages. Last tested address = 0x%06lX\n\n", limits.u32[0] - pageAddrSize);
                    return 0;
                }
                limits.u64 = EZBL_ReadTablePair(&tblRdPtr); // Increment to next EZBLAppSpaceGeometry
                if(limits.u32[0] < endLimitAddr)            // Still on the same erase page?
                    i--;
            }
        }
        *eraseState += 1u;

        EZBL_printf("\n0x%06lX  blank checking", limits.u32[0]);
        if(!EZBL_IsPageErased(limits.u32[0])) // Don't waste time or endurance if the page is already blank
        {
            if(limits.u8[2] >= 0xF8u)
            {
                EZBL_printf("\n    Reached Config bytes @ 0x%06lX, restoring and calling EZBL_EraseAppSpace() finished\n\n", limits.u32[0]);
                EZBL_RestoreAppErasable(1);
                return 0;
            }
            if(EZBL_IsEraseRestricted(limits.u32[0]))  // Don't erase this address if it is in the .text.EZBLNoEraseRanges section, such as user pages reserved for emulated data EEPROM
            {
                EZBL_printf(": erase restricted; skipping");
                continue;
            }
            EZBL_printf(": not blank; erasing");
            EZBL_NVMKey = keySave - (0xFC21u - 0x03DFu);
            EZBL_ErasePage(limits.u32[0]);
            EZBL_RestoreAppErasable(0);         // If we've erased some flash Config words, restore their default values
            return 1;
        }
#if defined(EZBL_DEBUG)
        else
            EZBL_printf(": blank");
#endif
    } while(--blankRepeats);

    return 1;
}

 
Please anyone at Microchip, have a look at this. The problem is in the function implementation but that code is so poorly structured I am not really sure I can fully understand it.
#9
antoniovazquezblanco
New Member
  • Total Posts : 10
  • Reward points : 0
  • Joined: 2019/01/30 04:11:09
  • Location: 0
  • Status: offline
Re: Unable to upload firmware with EZBL on dsPIC33FJ128GP804 2019/12/13 09:27:22 (permalink)
0
More than a week has passed since the last time I got any kind of communication from either this forum or Microchip support services despite my effort to call them repeatedly and two update requests on the open support ticket.
 
Support has been very poor until this moment and I had no chance to talk to anyone in order to provide details about the error I've found or to get any feedback on how to properly implement the broken function and submit a patch.
 
Please, anyone at Microchip, get in touch
#10
Jump to:
© 2020 APG vNext Commercial Version 4.5