Re: [Openocd-development] (patch) Change target script for LPC2478
On 4.12.2010 13:35, Freddie Chopin wrote: Speaking about this right/wrong policy - it's said that reset_config does not belong to target config files, yet you haven't changed that, but left these wrong command there... How come? Funny thing, each time I recall a discussion about LPC2xxx scripts, the discussion always quickly drifts to state where there isn't even a simplest attempt to try to make any good out of it. Most of time, there are good points in both (or several, even) camps but I'm sorry to say, that you who seem to do the most development are making the decisions as *you* think what the users want. That said, I don't feel much like contributing to any of this but just trying to make it all to work for me and all the companies I work for. Personally I don't like using NPX's ARM7 devices due to the stupid hardware where the user software on the flash is executed – only gods know how many lines - before JTAG gets grip on the device. One can deal with it, but not elegantly out-of-box, which I think should be the target for all the OpenOCD development. Ok, I admit that of course not everything can be universal – and should not be as it is just pure impossibility – but good examples for necessary steps to get everything running is good way to go. For what it's worth, I think the interface and target scripts should be as general as possible. Need of board file shouldn't be a bad thing? This is a great place to put everything product specific configurations, e.g. crystal speed. This *can* vary and thus not changing the target script itself makes it useful for *all* boards being used. About the programming speed: I've heard a lot of complaints about this. It's not about the time wasted in minutes per day. It's just purely about convenience of use. The developer needs to try out something – sometimes by trial and error – and more you have to wait the more you hate it. It's like using a poor text editor. If the response between key press and display is slow, it's pain in ass to use although it surely isn't obstacle for getting the work done. I don't know, this seems to be one of those very touchy topics so most likely I'm not coming back to this anymore, but hope this gives a new view to the discussion, and hopefully you can find a consensus of some kind. With best regards, Petri ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
If you don't see what's wrong about forcing every single LPC2xxx chip to use 12 MHz even if that's not the *correct* frequency for their board ... I don't know what more I could try to explain. I may have missed something in here, but why trying to specify a crystal frequency? Can't we use 4 MHz in here, IF we are setting the clock source to internal RC oscillator in reset-init script anyway? And, Freddie, I hope you can bear with this conversation. I think that these things discussed in here does relate to each other, although some of them needs to be addressed separately really. In all and all I'm quite thrilled about this as finally I get some light shred to this LPC2xxx mess. Your proposed script layout is A LOT better than any I've seen so far. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
BTW I have also attached a reset-init script that not only does a soft_reset_halt and vector table remap, but also disables MAM and PLL after reset - without that two steps I experienced really crazy behaviour in a very simple and correct code while debugging. This is a little bit same what we have done recently in here. I have never figured out how these scripts could have worked out of box for anyone unless using internal RC oscillator as the only clock source Without dealing with this things went crooked from time to time. What we actually did was making another procedure function called activateInternalOsc to target script that basically does the same things described here previously; disabling PLL, switching to internal RC oscillator, etc. Most importantly: putting the target device into /known/ state. This way we didn't have to worry about what crystal or PLL settings the device is used with. This function is called from reset-init event. We also made another procedure function called writeToInternalFlash that can be evoked when we want to use OOCD just to program the FLASH memory. One of the first things this function does is calling the activateInternalOsc, again to bring the device into known state and then perform what is necessary for flash programming. - JTAG_FREQ - CRYSTAL_FREQ / 8 works for me all the times, but CRYSTAL_FREQ / 6 - not (in the .tcl file I divide by 8 now) Agreed. Divided by 8 seems to be a more stable option in here as well. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
Why are you doing a soft_reset_halt? Why not? If this command is forbidden / wrong / whatever - remove it. If it's not, why do you care if I use it? Without that command it does not work. Or maybe I just don't understand the meaning of reset init? For me that is do a reset, init everything that should be initialized. If that's not the case, then the name should be changed, as it's misleading. I asked because I recently removed soft_reset_halt from lpc2478.cfg because it made things fail. I have no idea *why* it fails, so I hoped that you could shed light on that problem. We have fiddled so much with the config files in here that I lost track of affects long time ago. But in our current script we use soft_rest_halt as well (while using LPC23xx series, I'm not sure if we have tried it out with LPC2478 - we do have board for this as well). Bottom line is that it works for us - I don't know about other people or even less why it works without. Now following is just flow of mind thus may include major errors but hopefully will arise some conversation. What is the purpose of reset-init event? In my opinion it is where we want to get things back to the beginning. Performing system reset may reset other hardware on target board as well and may cause some major trouble while debugging. I don't like doing this anyway as it causes the EmbeddedICE logic to reset as well and OOCD to lose control for a moment. Soft reset makes a fake reset by altering the program counter, leaving the hardware to probably steady yet unknown state. This is why we need additional steps to configure some peripherals or clock source to fixed, known state as discussed before. Then we let the embedded software to handle rest of the initializations - just like if it was coming out from any ordinary reset. From what I have experienced, soft_reset_halt is a safe way of reseting the system. Then again the problems we have had, may all be just our own fooling with the OOCD and that utterance may not be true. OOCD isn't one of the easiest choices for debugging on the market. Regards, Petri ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Flash programming confusion with v0.1.0
Unfortunately OOCD mocks me about 'invalid command name target_script_0'. I just don't understand why, the same problem occurs with e.g. 'flash probe' etc. I'm probably missing something there but can't figure out what it is. If I leave out the target_script 0 and shutdown, I can connect the OOCD with GDB and start debugging without any problem at all (though for now, only a tiny project tested so far). target_script was removed in favor of using events. There is an appendix in the manual that explains how to convert to the new syntax. Thanks for pointing it out, not sure why did I miss this one with the target_script. But unfortunately I still do get errors like: invalid command name flash_probe. Same goes for e.g. flash info but flash bank seems to work just fine for me. I must be missing something big time... Regards, Petri ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Flash programming confusion with v0.1.0
Greetings, This is my first post to the list so please bear with me as I couldn't find the guidelines of the list. I have so far used very old version of OOCD and now wanting to upgrade. I compiled the tagged 0.1.0 code in cygwin and have also tried to run the win32 binary of it. However it it seems that I'm unable to execute several commands, e.g. target_script or flash probe etc. My tools of trade are Olimex JTAG's and NXP lpc23xx micros. I made my own interface, target etc files for OpenOCD as suggested by the current documentation. To put things short, this is about what I have made so far (comments etc removed): script telnet_port tcl_port gdb_port gdb_memory_map enable gdb_flash_program enable interface ft2232 ft2232_device_desc Olimex OpenOCD JTAG TINY A ft2232_layout olimex-jtag jtag_khz 600 jtag_nsrst_delay 200 jtag_ntrst_delay 200 reset_config trst_and_srst srst_pulls_trst jtag newtap $_CHIPNAME $_CHIPTYPE -irlen 4 -ircapture 0x1 -irmask 0xF -expected-id $_CPUTAPID target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm7tdmi-s_r4 $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x4000 -work-area-size 0x4000 -work-area-backup 0 target_script 0 reset programming.script flash bank lpc2000 0x0 0x7E000 0 0 0 lpc2000_v2 14765 CALC_CHECKSUM init reset shutdown /script Unfortunately OOCD mocks me about 'invalid command name target_script_0'. I just don't understand why, the same problem occurs with e.g. 'flash probe' etc. I'm probably missing something there but can't figure out what it is. If I leave out the target_script 0 and shutdown, I can connect the OOCD with GDB and start debugging without any problem at all (though for now, only a tiny project tested so far). Unfortunately it seems that there are very little examples around for the new version(s) of OOCD, even in SVN... With best regards, Petri ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
