UNABLE TO PROGRAM PIC32 DUE TO FLASH ERROR: "Program memory is not blank"

edited August 2022 in Build-it-yourself

My Cyton board is fully assembled and while I had a major victory with getting the RFDuinos to work (which was documented on another thread), that was rather shortlived. The next major issue involved having to program the chip PIC32MX250F128B. Since I assembled the board from scratch, it's obvious that the PIC would be blank or have a minimal factory bootloader, nothing which would allow it to communicate with Arduino or be programmed OTA via the RFDuinos. So, I knew I had to flash the PIC and found the requisite bootloader UDB32_MX2_DIP.hex on one of the OpenBCI github links (will have to post that later).

NOTE: The chipKIT github hosts a relatively newer version of UDB32_MX2_DIP.hex (~189 kB) which has been compiled by a newer version of MPLAB, but for some reason, the new one is NOT recognized as a valid firmware by their own IDE or IPE when you attempt to import or load the hex for flashing. Strange, I know.. but just thought I should mention this, incase someone experiences the same issue. Anyway, I stuck with the older version of the bootloader provided here on OBCI's Github archive (which is only ~8kb)
.
Next: Opened MPLAB IPE v4.15 (I havent installed their more recent v5+/v6+ versions, in the interest of saving space on my drive). Set the ICSP option to "Power Target Circuit from Tool" and then clicked Connect. PICKit3 detected the PIC32 chip successfully and this was the initial log output:

    Connecting to MPLAB PICkit 3...

    Currently loaded firmware on PICkit 3
    Firmware Suite Version.....01.51.08
    Firmware type..............PIC32MX

    Programmer to target power is enabled - VDD = 3.300000 volts.
    Target device PIC32MX250F128B found.
    Device ID Revision = A1

I loaded the working version of the UDB32_MX2_DIP.hex bootloader and was able to burn it successfully to the chip using PICKit3, that went well. The blue LED started blinking gleefully, so I knew it was ready to accept new code. So far, so good!
.
Next, I attempted to upload the DefaultBoard sketch to the PIC from within Arduino. I figured that since the bootloader was already flashed, it should be able to accept the firmware OTA, so I switched the Port# to that of the Dongle (which had already been flashed with RadioHost32.hex by now). The compilation was successful, however the upload failed. Please see the error as displayed below:

.
Out of curiosity, I decided to see what would happen if I flashed the PIC with a blank sketch instead, and lo & behold, that was flashed successfully to the PIC! (see below):

Coming back to the Cyton firmware: I tried uploading DefaultBoard several times, checked all the wiring, brought the RFDuinos closer to each other, etc.. but nothing helps. Btw, I've already read through this entire detailed thread for clues but none of the tips have worked for me at all: chipKIT uploading tips & restarting bootloader

.
Finally, I abandoned the Arduino-RFDuino-PIC route and decided to flash the firmware directly using PICkit itself. Copied the compiled DefaultBoard.ino.hex file from the Temp folder and placed it in a more convenient location. Loaded the DefaultBoard firmware hex into IPE, clicked Program and this is the error that results:

.
When I try to Erase the chip and do a Blank Check immediately after, the blank check fails with a similar error:

Blank Checking...
Program memory is not blank.
Blank check complete, device is not blank.

Seems to be an issue with writing to the chip's Flash starting from memory address 0x1d010000 onwards, I deduced this after running Verify.. this was the result:

Verifying...

The following memory areas(s) will be verified:
program memory: start address = 0x1d000000, end address = 0x1d01ffff
boot config memory
configuration memory

program memory
Address: 1d010000 Expected Value: 10600028 Received Value: 0
Verify failed

I do suspect that this Program Flash region is being write-protected, so is there a specific #pragma or predirective that needs to be specified in the code in order to disable the chip's protection scheme?

I also read on another forum that one person was able to get past this error by programming the PIC in Low-Voltage mode, while they weren't able to do so in regular mode. But I dont see anything specific about LVP mentioned in this PIC32's datasheet, does anyone have any information or clues to this??

.
Tagging @wjcroft , @Shirley , @retiutut for any help & guidance in this matter

Comments

  • wjcroftwjcroft Mount Shasta, CA

    Sent you an email along with one of the OpenBCI engineers most familiar with flashing issues.

  • Okay great, thank you William! Looking forward to hearing from Ioannis, hopefully soon..

  • @wjcroft: Is there another way to get in touch with Ioannis? Or if there's anyone else on the team who might be familiar with this error? It's been more than a month since I've been facing this issue and my progress with the Cyton board has been totally stalled due to this.

  • Months later and this issue has only been partially resolved by replacing the PIC32 chip on the board with a new one that I sourced from another supplier. I am now able to burn the bootloader with MPLAB IPE, followed by the PIC code via Arduino (v1.8.12) successfully. However, when testing the board with OBCI GUI, I am not receiving any data at all from the board. When I check the Raw log file, only the initial header is present but no data has been recorded at all. Finally, even if I attempt to send any of the board commands via the Serial Monitor, I do not receive any responses back from the board. From the point of construction, the Cyton board is completely done now.. but I'm gonna need some tips & pointers on how to troubleshoot this lack of data stream.

    Calling @wjcroft & @retiutut : How do I even begin to debug this board??

  • wjcroftwjcroft Mount Shasta, CA

    How do you know that the usb serial port data flow from the laptop to the Cyton (and back) is working properly? You mentioned the RFduinos are working here?

    https://openbci.com/forum/index.php?p=/discussion/comment/18091/#Comment_18091

    Perhaps one way to debug is to upload a tiny 'echo' program to the PIC32 that echoes back what it receives on the serial port. Then see if you can verify the full path working.

    It's also possible that your radio channels on the two RFduino's are not aligned. There is an AUTOSCAN feature built into the GUI, that realigns the radio channels, if not matching. This feature only uses the serial port commands unique to the RFduinos. Those commands are not seen by the PIC32.

    William

  • edited January 6

    Hi William, yes I'm sure that the radios are working perfectly fine because they are able to detect and communicate well with each other over Serial COM3. Within the GUI v4+, the Radio Config Status shows 'Success: System is Up' and clicking Get Channel yields: Host & Device are on Channel 20. However, once I attempt to start the Cyton LIVE session, it fails and then displays an Init error in the status bar, as seen here:

    I suspect that there is the PIC is not communicating with its RFDuino properly, there's certainly a lack of data flow. Your suggestion to test the PIC with an echo program sounds good, but I'm not proficient in coding for PIC32. So, if you could share any code examples or test programs that are used by your OBCI staff to test the Cyton boards, that would be most helpful, thank you!

  • wjcroftwjcroft Mount Shasta, CA

    You do not have to code in PIC assembler. Just make a tiny Arduino program loop. Or modify the default program. Check the code to see how the serial port functions read and write the RFduino port. If you have a scope you could check the mainboard RFduino serial transmit pin to confirm that it is reaching the PIC serial receive pin. And conversely if the PIC transmit serial is reaching the RFduino receive pin. You can also do continuity checks on these routes with a simple ohmmeter.

  • Thanks for the suggestions, @wjcroft! So here's what I did.. I wondered if I could use any of the Debug examples that came with the OpenBCI library instead of having to write it . So, I settled for the BoardNoAccepSDWifiDebug example and made a tiny modification to it, just so I could see if there was a change in streaming status. Also, I realized that instead of having to feed my Cyton board with an external signal, I could use its own internal signal commands to see if the board was able to detect or stream the test signal. Please see this screenshot, where I entered the displayed commands in sequence and got the following responses:

    So, as you can see here, my initial assumption about the lack of communication between the PIC and RFduino was wrong. There is indeed sufficient communication occurring between the two, otherwise I wouldn't be able to upload to the PIC OTA via Arduino and the dongle.. and I am able to print to the Serial port as well (visible on the Serial Monitor, but this is obviously for debug purposes only). The problem seems to between the PIC and the ADC, or rather, there is a lack of data streaming. I mean, the PIC does seem to be reading the ADS' device ID# correctly (although the LIS3DH shows 0x00). But either way, there is no streaming of actual/analog data happening at all, whether it's with the internal test signals or external inputs. Is there something I'm missing here when it comes to using the internal test signal correctly??

    Also, the line I added to display any Change in Status does indicate the the board.loop is running. But it's as if the PIC is not receiving ANY of the ADC data at all, not even 0's.

Sign In or Register to comment.