I have been trying out a NXP LPC2378 demo program that communicates between two CAN interfaces (from current sample software kit v1.5 on NXP web page).
I have tried the demo program (named CAN) on the Keil development board, and everything works ok - both when run as a LPC2378, and when run as a LPC2366.
When I try to run the software on our own hardware, I also have to drive the standby signals for the two CAN bus driver chips. One standby signal is controlled from a pin on P0 and one signal from a pin on P1.
The software is configured to use Fast-GPIO and the strange thing is that I can manipulate P0 signals ok, but no matter what I try, I always fail to configure any P1 signals.
The software sets the relevant P1 signal as an output, and I single-step one instruction. Then the Fast-GPIO dialog for P1 shows the signal back as an input again. Same thing if I toggle P1 bits in the dialog. As soon as I step one instruction, all values in the dialog gets reset (direction, mask, set, clear). The problem can be seen before any ISR have been registered.
To my knowledge, there are no power configuration for the I/O ports, and the single flag to switch between Fast-GPIO and the older GPIO mode should affect both P0 and P1.
All the relevant signals are configured as GPIO and my only working way to set the pin high or low right now is to switch between pull-up or pull-down.
With our original 20Mhz crystal, I did run with 240MHz PLL and a number of different clock frequencies. To eliminate an error source I have switched to a 12MHz crystal (same as Keil eval board and expected by NXP demo code), but still same behaviour.
Has anyone seen about this behaviour? I am running the current version of the tools (MDK 3.11 with ULINK2 and one beta DLL to support PLL frequencies below 275MHz) and I don't have any problems controlling P1 in my own projects, when running on the same hardware).
The main difference between this project and my "real" projects is that this build runs in RAM.