WallaceIT
ERROR at address 000000: written 0200 but 0000 read!
picberry PIC Programmer v0.3 Device Name: PIC24FJ256GB106 Device ID: 0x00001019 Revision: 0x00000004 Writing chip...[[ 0%]]
ERROR at address 000000: written 0200 but 0000 read!
DONE! Exiting program mode...
Hi,
I am facing above issue while programming using picberry, Any idea what might be wrong.
Are you using Raspberry Pi OS 32bit or 64bit?
I had the same error when trying picberry under 64bit OS ... but I added a pull request today which fixes the 64bit OS issue
after pulling #25 and attempting to upload a hex file, i was getting the same issues on the CM4. i hooked up a scope on the PGC and PGD lines and they appeared to be functioning as expected. they seemed stable, so i'm not sure why it wasn't reading correctly. i tried recompiling the project on a new 32bit image with a pi3 i had lying around, but i was getting the same issue.
i was still unable to successfully upload the hex file. i knew that some communication was working as i could read the device id and the verification was failing at different steps... there could be a handful of issues. the data lines are too choppy and noisy, the pi can't control the GPIOs on time, or the pic can't read fast enough??? i'm not sure what the issue is.
after some trial and error i was able to get some success! after reviewing the read_data function in dspic33f.cpp, i tried to slow down the clock sleep by adjusting DELAY_P1A and DELAY_P1B to 10us. after waiting patiently i was pleasantly surprised that the upload had succeeded!
i hope documenting my solution helps others, but i'd like to work on a solution that works for everyone. personally i just joined this project, but i'm willing to collab with people interested. i propose we start an active fork and iron out some of the bugs.
I also have those issues when trying to flash from a container where vscode remote server is running.
Some background info: I am trying to build a CI test infrastructure for our products based on the picberry library instead of hooking up lots of ICD3/Pickit3 devices (which are also not really that reliable :D) As this will be connected and used from a Bamboo instance, I chose to go the containerized way. I also use the same container as devcontainer in vscode, and there I experience those exact errors as long as the vscode server is running inside the container. When I stop it, I can flash without problems.
So it seems this is some kind of performance issue ... I can see in top that the vscode server has some 100% cpu load spikes every now and then, so I guess this is preventing the picberry timing from functioning correctly.
I already spoke to a colleague of mine about this issue, and he agreed that some of the busy loops used in the picberry lib could be done in a much better way ... maybe that would be a good starting point in a hypothetical fork ;)
thanks for getting back to me on this. i didn't expect this to be a resource issue considering the CM4 has 4 cores.. but you caught me red handed, i've been doing most of my development with vscode's remote ssh feature. i'm guessing based on your results there are some interruptions during the gpio read process. so goes the struggle for real time performance on linux...
i have just a few ideas for mitigation on this problem.
- cpu allocation its possible to limit the numbers of cpu on the vscode devcontainer to promote a better likely hood of gpio reading on time. or the other way could be to cpu pin the picberry process to a dedicated cpu.
- process priority run the process on higher priority level to prevent other processes from interrupting.
- context switch policy change the policy that promotes better real time context switching like FIFO
- DMAgpoi w/r (this one is just for fun) its possible to allocate physical memory to the DMA controller to GPIO w/r. we can use a PWM signal to control the timing of the output and chain frames together.
i'm not exactly sure what the most appropriate approach is here for the general user of this repo. the problem is the unwanted context switch which makes implementing protections difficult for user space software. if there's a better way to recode the IO loops to prevent switching i'm not sure. the obvious solution here is to leverage hardware to give cycles back, but there's no support for what we need and the DMA idea is totally ridiculous as it involves unsafe manipulation of physical memory.. yikes. if you have any more ideas of how to improve this code or the reading process i'd like to hear. otherwise i'll most likely just decrease the write/read speeds or limit the devconatiner allocated cores.
Ok, the idea with the process priority should be the easiest to test.
I like the CPU allocation idea best, if it was possible to only restrict the vscode remote server process to one CPU ... I don't want to limit the container as a whole, as there are other processes in there which I need for the CI automation.
Maybe another idea would be to use the realtime capabilities of the kernel. I'm no expert in this but I know that for audio processing under linux the jackd server wants that ... I just don't know how to achieve this programmatically... If there is some sort of kernel interface or a realtime lib which we could use in the picberry code ... ?!?