We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, I've a strange problem with fast GPIO on LPC2378. Specifically, I can neither set nor reset the pin 4.1 of GPIO port, while I can set and reset pin 4.0, 4.2 and 4.3. Moreover, if I execute the code step-by-step with Ulink2 debugger I find a problem also with pin 4.2. In fact with my oscilloscope I see that after the reset instruction FIO4CLR = 0x04; I see the level of the pin goes low but soon after it goes suddenly to high level. Moreover if I watch the value of FIO4PIN on the watch window I see a value different from the one displayed by the peripheral window of FAST GPIO. I suspect there is bad interaction between uVision and my software execution. Is there any register I have to configure to avoid this strange behaviour?
Thanks and bye
Demis
Check if you are using the latest MDK which can display correctly also Fast GPIO.
Normal memory read of Fast GPIO with the debugger disrupts the Fast GPIO registers (specific chip behavior) and therefore uVision uses a special mechanism to read Fast GPIO without the mentioned side effect (you need UL2ARM V1.32 or higher).
Thank you for information! I'm currently using uvision V 3.53 (I don't know if this is the latest one) and ulink2 with firmware version 1.20.
Is it possible to update firmware inside ulink2?
And what about the fact that port 4.1 is not affected by my set and reset instructions? Any suggestion?
Thank you and regards,
Go to uVision menu Help - About ... and check the Target DLL: UL2ARM.DLL Version number.
V1.32 or higher (part of latest MDK) is required for correct display of Fast GPIO.
ULINK2 FW will be automatically upgraded to V1.30 (the first time you use it).
I've the UL2ARM.DLL V1.30. How can I do to update this dll? Should I download the whole MDK 3.15b?
Thanks and regards
Install MDK 3.15b
Hi Robert,
Can you elaborate on this particular problem with FastGPIO as this is the first place I have seen this discussed ?
In particular :-
1) Which devices are affected ? 2) What are the symptoms of the problem ? 3) What workaround is required ?
I have not seen this in the errata sheets for the LPC214x family that we use. I did report a similar problem to Keil last year (via Hitex) but I never got a reply or heard anything more about it. I gave up on FastGPIO and have been using standard GPIO since then.
Regards,
David.
1) Which devices are affected ? Initially it was present in all devices with FastGPIO (LPC214x, LPC23xx/LPC24xx). It could be that NXP has already fixed this in newer chip revision.
2) What are the symptoms of the problem ? The problem occurs only when debugging the target with a debugger (for example uVision + ULINK) and reading/writing the memory where FastGPIO registers are located from the debugger. This will disrupt the FastGPIO registers (and the actual port). So it happens only when debugger accesses FastGPIO registers directly via JTAG. There are no problems when the user code reads/writes to FastGPIO registers.
3) What workaround is required ? Using a debugger that uses a special mechanism to access FastGPIO registers. ULINK driver (UL2ARM.DLL V1.32 or higher) supports this.
I gave up on FastGPIO and have been using standard GPIO since then. I would encourage you to use FastGPIO in your application whenever you need fast I/O handling. I have a lot of experience with it and it works without problems.
Thanks Robert,
As always, very informative.
David