Messages

Suggestion for SOLUTION:

constraint: we have GND,VCC,RXD,TXD,ISP_ENABLE and Reset on our programming connector.

As we got no feedback by NXP yet and need to redesign the PCB shortly, we decided to work around the problem the following way:

We leave the internal reset as is, including the watchdog stuff - and accept periodic reset pulses.
We make the reset-ic's output signal a bit softer (1000 Ohm serial) from IC to ARM
As programming adapter, we use the FM suggested hardware with a slight modification.
The reset signal will not be tristate, but ordinary 0/1, so FM is capable of driving the reset hard to 1.
As long as the incoming DTR (-> becoming RESET) is a clear signal, this should work fine, and the watchdog should have to remain in its doghouse

Problem located and fixed.

The ISP routine seems to toggle/glitch a pin that we happen to use for our external watchdog device. (it is P2.13 on 2366) So the dog is bitchy and kills the ARM roundabout every second. This explains quite well why only short commands work

Sorry for overseing such an obvious point. !!! Many apologies !!!

Question:
Anybody knowing which pin to use for a watchdog? or other way round - is there a spec out by NXP <<guaranteeing>> "silent pins" ?

tia
Willi

Andy,

First of all and __VERY__ important to me:
Please let me say I really appreciate your helpful contributions!!

I took a break and made something completely different to get away from the problem and to return with new "blank head" - as this is often helpful

So restarting HERE:

after commenting out any UART0 related code in my application I got a "Synchronized" almost immediately in Terminal after the 9k6 '?' , so I attached FM instead and was able to read Chip ID - so the basic transfer is working. BUT WHY ? you see me in 100% confusion
I thought an ARM reset would cause the CPU to sample the ISP-PIN and if in ISP mode, to never enter my code. How can then my code get executed and disturb the ISP communication ... ?!?!
(connection to read chip ID works up to and inkluding 230 k)

Then I tried to program and found it to be not working, no matter how low I set the baudrate (even at 9600). If I press <START>, it begins erasing sectors and then ends up in a dialog box saying:
[Operation Failed. (Failed to erase block nn)]  with n varying from say 2 to 6)

And, even more interesting is the fact I get no connection at all trying a different PC (Toshiba Tecra XPProSP2)

So put together, my intial single question ends up in three:

1) Why does my UART0 usage disturb the bootloader startup? (Code is imo supposed to be sleeping then)

2) Why does the programming fail?

3) What's wrong with my Toshiba Notebook?
(AS it is in the docking station I assume here that is not a "real" serial chip, but something glued to the bus via USB, so this might be same as with the different USB adapters here in the forum I guess .. but VERY disappointing !)

many thanks in advance

WILLI

OUCH !

did I miss something here? I was not aware that my "real application" must not use the SIO.
So I AM using UART0. May this be causing the problem ? btw quartz is at 12 Mhz

sorry, forgot: I am sending manually ? at 9600bd

OK, thanx

I was unsure if the stuff around those two signals was really optional - maybe due to some handshaking. So my simple jumper to GND and pushbutten reset solution *should* work. So I can start to look somewhere else.

(and yes, the SIO is set up properly, just doublechecked with terminalprogram and a second 3.3 RXD pin connected to just antoher terminal via level shifter. Both signals pass)

just fed the '?' manually during reset (autorepeatedly) , but no meaningful replies at all , looks to me like crap of this type "¿ÿïÿ¿ÿÿ<¿Ÿ¿<?ÿÿÿÿÿø"

but both SIO ways are fine (checked again thru shorting right at the socket -> all proper ? as expected)

Hey all,

Got autobaud problem at stage 1. - But right now I am using simplier hardware, just TXD and RXD , P014 driven to low via jumper on PCB and resetting manually.

I am aware of the suggested hardware (as seen on both the Keil PCB as well as the FM manual.

The question is if the two "connections" (talking of driving low here) DTR/Reset and RTS/P014 are <<really>> mandatory - eg if FM uses the RESET more often to stimulate the embedded programming firmware.

tia
willi behrens