-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
On-Board Programming #29
Comments
Actually, looking further at the datasheet (related to issue 1), i'm not sure anymore if hardware reset (PRSTB) is active high or active low. I had been assuming it was active low like so many other MCUs, but maybe the P in PRSTB means 'positive'? I don't see anything else to indicate one way or the other. I'll have to give it a try. If it is actually active high reset, maybe there isn't an issue. The button on PA5 could just be connected between PA5 and VDD instead of PA5 and GND, and code would test for a 1 instead of a 0. PA5 might need an external pull-low resistor (instead of being able to use the internal pull-up resistor) for this to function properly. |
Ok, after doing some further testing (related to issue 1), I can confirm that PRSTB is indeed active low (at least on the PFS154), so hardware reset can't be used when connected to the programmer unless we can solve the above mentioned issue with the programmer pulling PA5 low when idle. I did test with a 'user' button connected between PA5 and VDD (instead of GND), and a 10k pull-down resistor between PA5 and GND, and testing for 1 instead of 0, and that works fine. But, this configuration won't work for hardware reset (and is backwards to the way switches are usually wired up), so I would prefer it if we could fix the above issue somehow. |
Hi, Hardware reset needs to be enabled in the currently running firmware. Also the hardware reset is not helpful to enter programing mode. Programing mode can be entered only if you start to feed VPP voltage to PA5 prior to feed any voltage to VDD. And the voltage difference between VPP and VDD must be at least 2V. I tried a lot to program flash ICs in circuit but usually it fails as soon as anything is connected to one of the pins involved in programing (PA3, PA5, PA6) - this happens also with the original WRITER hardware and software from PADAUK. So unless you do not connect anything to PA3, PA5 and PA6 it is very very difficult to do in circuit programing. |
For the record, I'm successfully programming PFS154 in-circuit with connections to VDD/VSS, and PA3/5/6 which are connected to LEDs via 150ohm resistors. I didn't realise I needed PA4 for IHRC calibration, will add in next version. |
I've noticed two things so far that are less than ideal when using easypdkprog connected to a flash based IC that is on a board with various other components. I am curious if either of these can be solved by a change to the programming hardware and/or software. Please feel free to close or move this if this is not a good place for discussion related to this.
For issue 1, it appears that the programmer is pulling PA5 low even when it is idle. PA5 is an ideal pin to place a button as it can be configured either for hardware reset or for general user functionality. But, when the programmer pulls the pin low, the IC will always be in reset (if configured with hardware reset functionality), or always read as button pressed, even when using the internal or external pull-up resistors. This means the programmer has to be physically disconnected after programming before executing user code. After a quick glance at the programmer firmware and schematic, it looks like it is trying to idle the line (i.e. tri-state), but I think it is being pulled low because it is connected to one of the outputs of the opamp (i.e. VPP). Potentially an analog switch (i.e. CD4051 or similar) could be used for a true disconnect, but I'm not sure if that is worth the extra complexity. Is there any firmware way for the programmer to truly release the line (i.e. high-z)? Or, could the programmer perform a weak pull-up on the line in 'idle' state?
For issue 2, it appears that the programmer is not able to properly communicate with the IC when there is a crystal (and supporting caps) connected to pins PA6/PA7. If there is a need for an external crystal, it has to be connected to PA6/PA7. I think I narrowed it down to the capacitors, not necessarily the crystal. According to the datasheet, on-board programming should be ok as long as PA6 has less than 220pF of capacitance. The 32kHz crystal I am using only uses 22pF capacitors, so in theory this should be ok. I am wondering if the 100 ohm resistors on the programmer are contributing to the problem. The datasheet indicates a direct connection to the IC, not going through what I assume are programmer pin protection resistors? So, should the resistors be removed? Or, can the timing be adjusted in the firmware/software to make up for the extra resistance?
The text was updated successfully, but these errors were encountered: