Re: [Openocd-development] (patch) New board config for Embedded Artists LPC2478-32
Merged. Thanks! -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Hitex LPC2929 board script fix
Merged. Thanks! -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Fix sector layout for 512-KiB LPC2300/2400 parts
merged. Thanks! -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming)
How's this one coming? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) New board config for Embedded Artists LPC2478-32
On Sat, Dec 4, 2010 at 9:52 AM, Freddie Chopin freddie_cho...@op.pl wrote: On 2010-12-04 09:40, Øyvind Harboe wrote: Merged. Thanks! You know that this does not work the intended way without the new version of lpc2478.cfg file? Ah, right. It doesn't break any old config scripts, so I'll leave it be for now. That other discussion is still open. also that name is very long compared to other names. I care about that because I have names in a dropdownlist on ZY1000 :-) -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 00:00, Michael Schwingen wrote: On 12/03/2010 11:11 PM, Freddie Chopin wrote: How can this be unreliable? LPC23xx/LPC24xx after reset use 4MHz internal clock. Doing reset halt sets that clock and prevents any code from changing that (let's not talk about broken cases, because a broken case can be found everywhere), so what's wrong with this approach? So flashing is only supported after reset halt? That adds another step during development in case I work with different clock settings. That's what I meant by broken: flashing does not work until I bring the board into some configuration (reset halt) that is different from what I normally need. So you're all about correctness and you don't reset halt the chip before flashing? How is that correct? Actually flashing does not work if you don't reset halt the chip. The need for halting is obvious. The need for reset is not, but think about what would happen if your code would have a timer (or any) interrupt enabled and running during your flashing. Actually you DO need to get the chip in some known (and specific!) condition to flash it. Moreover - the new config file works exactly the same way - you can specify the clock as a parameter, but to be sure about it you need to reset halt or reset init. Why use big chip? LPC2478 has an LCD driver, and there is no chip with LCD driver that has less flash. Because for developement of the project you take big chip just-in-case, and choose right one (regarding flash size) for production when the code is ready. Anyway - we should be talking about the average size of the upload, and that's never 512kB - the code has to grow from 0 to this size during developement. BTW - you use libusb of ftd2xx (if you use Windows and FT2232 based JTAG)? I'm asking because if waiting 10s is worth breaking configurations of OpenOCD's regular users, then I hope you use the fastest library for the process. C'mon! 10s?! Don't read mailing lists and that will save you much more time (; It's not about the total amount of time, it is about interrupting my work on every upload. Now how is the operating system I use relevant for this discussion? Just because some things in OpenOCD might be improved does not mean that we should slow down other operations as well - for no benefit, just because you declare that it should be good enough for everyone. Operating system matters because ftd2xx is faster only on Windows - in Linux it's slower or the same. I'm not telling slow down - I'm saying don't use this file that can speed things up because it also makes using OpenOCD a bit harder. Technically this file does not speed anything up, because there is no PLL setting anywhere in it - the new board config file (another patch) does speed things up and it can speed things up exactly the same way now or when lpc2478.cfg would use some default value. BTW why isn't the pll configuration function placed in target file? Then let's provide a board config file that works fine on those barebone applications where OpenOCD does not need to know anything beyond the CPU. But there's no point in having a board file that in reality is not for board but for target, that will do nothing more than include target file... What for? What does that make easier? If one has it's own board with some chip I don't think one would look for config scripts in board directory... I wouldn't. Please - try to make OpenOCD more user-friendly, not user-hostile! The config file you need *is* for a board, so it belongs in the board directory. The LPC target alone can not know the clock used. If I'd have the microcontroller hooked up directly to JTAG and PSU with thin cables would that be considered a board too? It's just a simple microcontroller! It needs almost none configuration on OpenOCD's side - every board with LPC2478 was using the old file and it was fine. The problem is that right now OpenOCD provides all I need, because there is no lpc2478_std config file, lpc2478.cfg works just fine - I (and anyone willing to use OpenOCD with that chip) would have to create it first. Same amount of typing and user experience? I doubt it - right now I don't need to know ANYTHING about tcl, OpenOCD's config files etc. They work out-of-the-box. People working with more complex boards are not forbidden to set right clock speed now. Actually I think they managed, because I've not seen any complaints... Um - no. I proposed to add that file to OpenOCD, so no user would need to learn TCL or write his own config file - just like it is now. You said use some file, not I'll add that to OpenOCD... I've made a proposal to create target files for every chip that OpenOCD could support and organize them neatly in directories. This has a disadvantage of having hundreds of files. Your approach (having board file just because target file was made dependent on some parameters) creates a need for otherwise useless files... It is not useless - it enables other
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 00:32, Rolf Meeser wrote: This is a misconception. When OpenOCD tries to take control after a reset, the CPU is already running. ISP mode or existing user firmware may or may not have changed the clock tree. Like it or not, but there is no a priori knowledge of CPU clock. When doing reset halt (which would halt the chip immediately after reset) the clock would be 4MHz. With LPC23xx you are in the same situation as with older LPC2000 which required an external crystal. The operating frequency is *not* a target parameter, it is a board/application parameter. Indeed - older LPCs don't work this way, because there is no internal oscillator. So why change lpc2478.cfg that CAN work with default value, and leave all older files that CAN'T? C'mon! 10s?! Don't read mailing lists and that will save you much more time (; I'm afraid but professional embedded development is different. Speed matters. Why would I renounce the comfort of a fast download when I can get it for free? I want OpenOCD to be as efficient as possible. If you don't like that, you may always run at a slower clock, and help yourself with a cup of tea. I like that I can take my mind off firmware for a few seconds and trade a few words with a co-worker sitting next to me. Actually professional embedded development in here must not look like in your place - we're not racing for the fastest upload on the market, because the client probably would not care if you could deliver the product a few hours earlier due to these tremendous savings on upload time (; But there's no point in having a board file that in reality is not for board but for target, that will do nothing more than include target file... What for? What does that make easier? If one has it's own board with some chip I don't think one would look for config scripts in board directory... I wouldn't. Please - try to make OpenOCD more user-friendly, not user-hostile! That's the whole point of OpenOCD's layered config file approach. Do you refuse to work with an LPC2138 device just because its target config file cannot include a clock frequency? There is no way to avoid a board file here. And at the risk of repeating myself, the situation for LPC23xx is the same. I've stated on multiple occasions that for me this whole policy is wrong. As for the second paragraph, you are wrong. All LPC2xxx target config files have that frequency embedded without possibility to change with some parameters in board config files and - somehow - people manage to use it without problems. And I like those files very much, because they work standalone, so in my favorite way. The problem is that right now OpenOCD provides all I need, because there is no lpc2478_std config file, lpc2478.cfg works just fine - I (and anyone willing to use OpenOCD with that chip) would have to create it first. Same amount of typing and user experience? I doubt it - right now I don't need to know ANYTHING about tcl, OpenOCD's config files etc. They work out-of-the-box. People working with more complex boards are not forbidden to set right clock speed now. Actually I think they managed, because I've not seen any complaints... Why can't you do with LPC2478 what you *must* do with LPC2148? I'm not getting it. We're talking about a three-liner: 1. your interface, 2. your clock frequency, 3. your target. That's clearly a no-brainer! I don't have to do that with ANY LPC2xxx file now. You're wrong here, because all these target files have frequency embedded inside without any parameters. Just for the record - typing names of 2 files in command line is more-no-brainer than creating a config file that includes them. I have a crazy idea - I think it is possible to measure frequency of the external crystal (and check for it's existence) with simple code using one timer. This way OpenOCD would work without specifying this frequency. It could then - before programming - measure it (backup-ing all settings of timer), switch PLL to max value (using external crystal or internal resonator, also backup-ing all settings of clock and PLL), flash, revert all changes made to clock, PLL and timer and voila [; Problem gone Nice idea. However, that goes way beyond what is required right now to get reliable programming at the maximum possible speed. Also, will this work without a reset init to get the system into a known state? I was thinking about embedding that within OpenOCD's flash handling code specific for LPC, not in config files. Right now you have to supply that speed, with such wise flashing algorithm this parameter would be useless (could be provided, could be omitted - freq would be measured then). Deep inside I have a feeling that this proposal is on a head-on collision course with your wish for simplicity... Technically, I do not know how you want to measure frequency without a timing reference. And why on earth would I *temporarily* enable the PLL to circumvent the difficulty of
Re: [Openocd-development] OpenOCD Cortex-A8 / S5PC100 support...?
Hi everyone, Ah, I should have added that voltage was the very first thing I checked. On the S5PC100 the JTAG runs at VDD_EXT which has a valid operating range from below 1.8V to above 3.3V, and the board I'm trying to bring up has VDD_EXT set to 3.3V (as designed, measured to ~3.25V), so this really shouldn't be the issue here. Cheers, Nick Pelling ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 12/04/2010 10:31 AM, Freddie Chopin wrote: On 2010-12-04 00:32, Rolf Meeser wrote: This is a misconception. When OpenOCD tries to take control after a reset, the CPU is already running. ISP mode or existing user firmware may or may not have changed the clock tree. Like it or not, but there is no a priori knowledge of CPU clock. When doing reset halt (which would halt the chip immediately after reset) the clock would be 4MHz. Wrong. I've explained that often enough. With LPC23xx you are in the same situation as with older LPC2000 which required an external crystal. The operating frequency is *not* a target parameter, it is a board/application parameter. Indeed - older LPCs don't work this way, because there is no internal oscillator. So why change lpc2478.cfg that CAN work with default value, and leave all older files that CAN'T? No, the lpc2478.cfg *CANNOT* work with a default, because there is none. Are you blaming me for not having changed all the other lpc2xxx.cfg files yet? I promise I *will* change them all. They *must* be changed. See below. But there's no point in having a board file that in reality is not for board but for target, that will do nothing more than include target file... What for? What does that make easier? If one has it's own board with some chip I don't think one would look for config scripts in board directory... I wouldn't. Please - try to make OpenOCD more user-friendly, not user-hostile! That's the whole point of OpenOCD's layered config file approach. Do you refuse to work with an LPC2138 device just because its target config file cannot include a clock frequency? There is no way to avoid a board file here. And at the risk of repeating myself, the situation for LPC23xx is the same. I've stated on multiple occasions that for me this whole policy is wrong. As for the second paragraph, you are wrong. All LPC2xxx target config files have that frequency embedded without possibility to change with some parameters in board config files and - somehow - people manage to use it without problems. And I like those files very much, because they work standalone, so in my favorite way. For me this policy is right. I'm willing to state this on as many occasions as required. Look at the ever so perfect standalone configs: lpc2148.cfg: The clock frequency is hard-coded as 14.756 MHz. Nobody will ever use this device with a 14.756 MHz crystal. Nobody. Never. Now assuming a realistic crystal of 12 MHz, the gentle user will use the device outside spec. With a 24 MHz crystal he might still be able to program the flash and verify correctly. Unfortunately he will have field returns, because the devices will certainly start failing after six months or so. This has already happened. lpc2103.cfg: The clock frequency is hard-coded as 12 MHz. So you're saying is that anybody using crystals of 10, 14.756, 16, 18.432, 20, 24 MHz has to accept that flashing won't work for him? Just because you don't mind failures here and then? The problem is that right now OpenOCD provides all I need, because there is no lpc2478_std config file, lpc2478.cfg works just fine - I (and anyone willing to use OpenOCD with that chip) would have to create it first. Same amount of typing and user experience? I doubt it - right now I don't need to know ANYTHING about tcl, OpenOCD's config files etc. They work out-of-the-box. People working with more complex boards are not forbidden to set right clock speed now. Actually I think they managed, because I've not seen any complaints... Why can't you do with LPC2478 what you *must* do with LPC2148? I'm not getting it. We're talking about a three-liner: 1. your interface, 2. your clock frequency, 3. your target. That's clearly a no-brainer! I don't have to do that with ANY LPC2xxx file now. You're wrong here, because all these target files have frequency embedded inside without any parameters. You don't do it now? Then you're failing *miserably*. Having embedded frequencies in the target files is plain wrong. It *DOESN'T* work. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) New board config for Embedded Artists LPC2478-32
On 12/04/2010 10:02 AM, Øyvind Harboe wrote: also that name is very long compared to other names. I care about that because I have names in a dropdownlist on ZY1000 :-) Feel free to change embedded-artists into ea! Not every company name can be as compact as Zylin :-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 12:05, Rolf Meeser wrote: When doing reset halt (which would halt the chip immediately after reset) the clock would be 4MHz. Wrong. I've explained that often enough. So you say that after reset and immediate halt the chip clock (for new LPCs) is not 4MHz? Are you working for NXP and do you know something that's not public? Because the manuals say something different than you. Bootloader has nothing to do with it, as reset halt will prevent it from running and changing anything. Indeed - older LPCs don't work this way, because there is no internal oscillator. So why change lpc2478.cfg that CAN work with default value, and leave all older files that CAN'T? No, the lpc2478.cfg *CANNOT* work with a default, because there is none. You say there is none, I say there is. There's no way we can agree. Are you blaming me for not having changed all the other lpc2xxx.cfg files yet? I promise I *will* change them all. They *must* be changed. See below. Sure - OpenOCD can be changed so that other - easier to use - tools would be more and more popular. For me this policy is right. I'm willing to state this on as many occasions as required. I can also say it's wrong anytime, so obviously we cannot agree on that subject too. Look at the ever so perfect standalone configs: lpc2148.cfg: The clock frequency is hard-coded as 14.756 MHz. Nobody will ever use this device with a 14.756 MHz crystal. Nobody. Never. Now assuming a realistic crystal of 12 MHz, the gentle user will use the device outside spec. With a 24 MHz crystal he might still be able to program the flash and verify correctly. Unfortunately he will have field returns, because the devices will certainly start failing after six months or so. This has already happened. Changing these 5 numbers is pretty straightforward and people do that (as OpenOCD works for them). I do. And are you saying that programming flash with wrong speed causes it to fail LATER? Again - do you have some secret knowledge from NXP that general public doesn't? lpc2103.cfg: The clock frequency is hard-coded as 12 MHz. So you're saying is that anybody using crystals of 10, 14.756, 16, 18.432, 20, 24 MHz has to accept that flashing won't work for him? Just because you don't mind failures here and then? Obviously this device cannot be used with 14.765 crystal because LPC2148 also cannot (see your paragraph above) - I don't know why is that, but if you say so... I don't have to do that with ANY LPC2xxx file now. You're wrong here, because all these target files have frequency embedded inside without any parameters. You don't do it now? Then you're failing *miserably*. Having embedded frequencies in the target files is plain wrong. It *DOESN'T* work. It works because I set the right frequency in files. This is pretty simple because I usually see no reason to use crystals different than 12MHz. Yes, this must be plain wrong, and you must be plain right, as the world is black and white. Ease of use does not matter, the most important thing is to be ultra-correct with everything. Do you actually care about the users, or maybe you're affiliated with Keil or IAR and your goal is to make using OpenOCD harder? Really - your change does nothing more than make OpenOCD harder to use, as everyone could change that frequency before that (and they did, as people were using OpenOCD successfully with those chips for a long time), but to do that no additional file was required. Again (and again) - default (whatever they may or may not be) values with warning for ALL LPC config files are GOOD. Adding board files with such default value is exactly the same as leaving default value inside target files. You loose nothing, we gain easy use and we are warned that this may fail in some way or another. Alternatively you may want to make that work: openocd -c set FREQ 12345 -f interface/... -f target/... Because now it does not work (at least it didn't work the last time I've tried). It would also be fine. The need for obligatory creation of otherwise useless files is not fine. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 12:05, Rolf Meeser wrote: For me this policy is right. I'm willing to state this on as many occasions as required. 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? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 12/04/2010 12:35 PM, Freddie Chopin wrote: On 2010-12-04 12:05, Rolf Meeser wrote: For me this policy is right. I'm willing to state this on as many occasions as required. 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? Don't start trolling. I know you can do better. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
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] (patch) Change target script for LPC2478
Definitely my last post on this thread. On 12/04/2010 12:33 PM, Freddie Chopin wrote: On 2010-12-04 12:05, Rolf Meeser wrote: When doing reset halt (which would halt the chip immediately after reset) the clock would be 4MHz. Wrong. I've explained that often enough. So you say that after reset and immediate halt the chip clock (for new LPCs) is not 4MHz? Are you working for NXP and do you know something that's not public? Because the manuals say something different than you. Bootloader has nothing to do with it, as reset halt will prevent it from running and changing anything. One last time. OpenOCD cannot halt an LPC2000 immediately after reset. It must let the CPU run, then try to gain control over the CPU as fast as possible. How fast it can do that depends on the JTAG clock and on delay settings. By the time OpenOCD has taken control, the CPU may have entered ISP mode (it does that if the flash contains no user firmware). In that case the clock will be 14.748 MHz, and not 4 MHz anymore. If there is valid user firmware, this firmware may have set the PLL to any value you like, leaving you with an unknown clock frequency. This process is not under your control. The only possible conclusion is that you cannot have knowledge of the CPU frequency even after reset halt. As a side note: This is the reason why PLL initialization of an LPC2000 device should first disconnect and disable the PLL before it configures/starts/connects it again. If the device runs standalone, this step is unnecessary (the PLL is off after reset). However, if you debug the application via JTAG, things are different: Your JTAG box may not be able to stop the CPU before the firmware starts the PLL. The debugger will then just set the program counter to 0, so that it *appears* to be the reset state. But it isn't. Running PLL initialization again on the now already connected PLL will let your system crash. That's a fact which you should accept. Not only because I do indeed work for NXP. Indeed - older LPCs don't work this way, because there is no internal oscillator. So why change lpc2478.cfg that CAN work with default value, and leave all older files that CAN'T? No, the lpc2478.cfg *CANNOT* work with a default, because there is none. You say there is none, I say there is. There's no way we can agree. If you follow the arguments above about clock frequency uncertainty, then with all due respect you cannot but agree :-) lpc2103.cfg: The clock frequency is hard-coded as 12 MHz. So you're saying is that anybody using crystals of 10, 14.756, 16, 18.432, 20, 24 MHz has to accept that flashing won't work for him? Just because you don't mind failures here and then? Obviously this device cannot be used with 14.765 crystal because LPC2148 also cannot (see your paragraph above) - I don't know why is that, but if you say so... I haven't said so. I said that nobody will do it. The LPC2148 will only be used by people who want USB. That requires a 12 MHz crystal, 14.756 MHz will not work. Besides the general nonsense of default frequencies in all these files, I took this as an outstanding example of a config file that will fit *ZERO* real world applications. Changing these 5 numbers is pretty straightforward and people do that (as OpenOCD works for them). I do. And are you saying that programming flash with wrong speed causes it to fail LATER? Again - do you have some secret knowledge from NXP that general public doesn't? You do not want to write a 3-line board file to describe your application, but you do accept having to modify predefined files, with the risk that they get overwritten next time you update OpenOCD? Are you teasing me? This is not the place to teach you about flash technology. Just a simple reminder: Flash is an analog component. Not applying a proper programming pulse will leave a cell charged at only say 30%. Every flash cell loses charge over time, but while the correctly handled cell keeps its charge for 20 years, the incorrectly handled cell may already fail after a few months. Yes, this must be plain wrong, and you must be plain right, as the world is black and white. Ease of use does not matter, the most important thing is to be ultra-correct with everything. Do you actually care about the users, or maybe you're affiliated with Keil or IAR and your goal is to make using OpenOCD harder? Let me quote Sergeant Hartman: What is your major malfunction? Really - your change does nothing more than make OpenOCD harder to use, as everyone could change that frequency before that (and they did, as people were using OpenOCD successfully with those chips for a long time), but to do that no additional file was required. Again (and again) - default (whatever they may or may not be) values with warning for ALL LPC config files are GOOD. Adding board files with such default value is exactly the same as leaving default value inside target files. You
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 13:59, Rolf Meeser wrote: Definitely my last post on this thread. If that's the case then there's no need to reply... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 13:59, Rolf Meeser wrote: Definitely my last post on this thread. On 12/04/2010 12:33 PM, Freddie Chopin wrote: On 2010-12-04 12:05, Rolf Meeser wrote: When doing reset halt (which would halt the chip immediately after reset) the clock would be 4MHz. Wrong. I've explained that often enough. So you say that after reset and immediate halt the chip clock (for new LPCs) is not 4MHz? Are you working for NXP and do you know something that's not public? Because the manuals say something different than you. Bootloader has nothing to do with it, as reset halt will prevent it from running and changing anything. One last time. OpenOCD cannot halt an LPC2000 immediately after reset. It must let the CPU run, then try to gain control over the CPU as fast as possible. How fast it can do that depends on the JTAG clock and on delay settings. By the time OpenOCD has taken control, the CPU may have entered ISP mode (it does that if the flash contains no user firmware). In that case the clock will be 14.748 MHz, and not 4 MHz anymore. If there is valid user firmware, this firmware may have set the PLL to any value you like, leaving you with an unknown clock frequency. This process is not under your control. The only possible conclusion is that you cannot have knowledge of the CPU frequency even after reset halt. As a side note: This is the reason why PLL initialization of an LPC2000 device should first disconnect and disable the PLL before it configures/starts/connects it again. If the device runs standalone, this step is unnecessary (the PLL is off after reset). However, if you debug the application via JTAG, things are different: Your JTAG box may not be able to stop the CPU before the firmware starts the PLL. The debugger will then just set the program counter to 0, so that it *appears* to be the reset state. But it isn't. Running PLL initialization again on the now already connected PLL will let your system crash. That's a fact which you should accept. Not only because I do indeed work for NXP. You may work for NXP, but you are wrong on this one. OpenOCD can halt the core before any instructions are executed. You may not believe me, but I've checked that. I've created a code that changes the value of Timer0 TC register in the second instruction (the first one is loading the address of this register): ldr r0, =0xe0004008 str r0, [r0] After this instruction this register should have a value equal to its address. Value after reset is 0. Remember that this is the very first code that will be executed! There is no vector table, these two instructions are placed at address 0 in flash. Value of this register is not used anywhere else, the timer itself also isn't. Open On-Chip Debugger reset_config trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain reset halt JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) srst pulls trst - can not reset into halted mode. Issuing halt after reset. target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x801f pc: 0x0124 mdw 0xe0004008 1 0xe0004008: e0004008 resume halt target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x801f pc: 0x0124 mdw 0xe0004008 1 0xe0004008: e0004008 reset_config separate trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain reset halt JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x00d3 pc: 0x mdw 0xe0004008 1 0xe0004008: resume halt target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x801f pc: 0x0170 mdw 0xe0004008 1 0xe0004008: e0004008 As you see having reset_config separate allows you to halt the chip immediatelly after reset - the value of Timer0 TC after reset halt is 0. That's why having default value (when having reset_config separate) actually is possible for the parts that have internal oscillator. The core is halted even before executing the code of internal LPC bootloader... I can see the first instructions of it, changing MEMMAP makes it possible to see the code I'm talking about above. mdw 0xe01fc040 0xe01fc040: arm disassemble 0 64 0x 0xe59f201c LDR r2, [r15, #0x1c] 0x0004 0xe3a03000 MOV r3, #0x0 0x0008 0xe1020093 SWP r0, r3, [r2] 0x000c 0xe2822028 ADD r2, r2, #0x28 0x0010 0xe1021093 SWP r1, r3, [r2] 0x0014 0xe3c03007 BIC r3, r0, #0x7 0x0018 0xe5023028 STR r3, [r2, #-0x28] 0x001c 0xe51ff004 LDR r15, [r15, #-0x4] 0x0020 0x7fffe178 SVC 0xffe178 0x0024 0xe002c014 AND r12, r2, r4, LSL r0 0x0028 0xe01fc000 ANDS r12,
[Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
This is directly related to the findings from this post:
https://lists.berlios.de/pipermail/openocd-development/2010-December/017405.html
I've only removed srst_pulls_trst and comments that mentioned that (and
comments that were not very helpful)
4\/3!!
From 74e3b52516be9211fa6ea6a89853ac7a3a1fa478 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Sat, 4 Dec 2010 15:45:40 +0100
Subject: [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
LPC2xxx do not require reset_config srst_pulls_trst. This can cause various
strange problems when flashing the chip, because reset halt actually allows
the chip to run for some short period of time and execute some code.
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
tcl/target/lpc2103.cfg |3 +--
tcl/target/lpc2124.cfg |3 +--
tcl/target/lpc2129.cfg |3 +--
tcl/target/lpc2294.cfg |3 +--
tcl/target/lpc2378.cfg |3 +--
tcl/target/lpc2478.cfg |3 +--
6 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/tcl/target/lpc2103.cfg b/tcl/target/lpc2103.cfg
index 714267f..7f14555 100644
--- a/tcl/target/lpc2103.cfg
+++ b/tcl/target/lpc2103.cfg
@@ -12,8 +12,7 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0x4f1f0f0f
}
-# LPC2000 - SRST causes TRST
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
# reset delays
adapter_nsrst_delay 100
diff --git a/tcl/target/lpc2124.cfg b/tcl/target/lpc2124.cfg
index c511589..df71bdd 100644
--- a/tcl/target/lpc2124.cfg
+++ b/tcl/target/lpc2124.cfg
@@ -12,8 +12,7 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0x4f1f0f0f
}
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
# reset delays
adapter_nsrst_delay 100
diff --git a/tcl/target/lpc2129.cfg b/tcl/target/lpc2129.cfg
index 103f18e..2587bf7 100644
--- a/tcl/target/lpc2129.cfg
+++ b/tcl/target/lpc2129.cfg
@@ -12,8 +12,7 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0xcf1f0f0f
}
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
# reset delays
adapter_nsrst_delay 100
diff --git a/tcl/target/lpc2294.cfg b/tcl/target/lpc2294.cfg
index 6f34171..ecf0599 100644
--- a/tcl/target/lpc2294.cfg
+++ b/tcl/target/lpc2294.cfg
@@ -14,8 +14,7 @@ if { [info exists CPUTAPID ] } {
adapter_nsrst_delay 200
jtag_ntrst_delay 200
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
#jtag scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
diff --git a/tcl/target/lpc2378.cfg b/tcl/target/lpc2378.cfg
index 65b554c..21fdd1b 100644
--- a/tcl/target/lpc2378.cfg
+++ b/tcl/target/lpc2378.cfg
@@ -16,8 +16,7 @@ if { [info exists CPUTAPID ] } {
adapter_nsrst_delay 200
jtag_ntrst_delay 200
-# LPC2000 - SRST causes TRST
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
diff --git a/tcl/target/lpc2478.cfg b/tcl/target/lpc2478.cfg
index df46c10..99c8ce9 100644
--- a/tcl/target/lpc2478.cfg
+++ b/tcl/target/lpc2478.cfg
@@ -16,8 +16,7 @@ if { [info exists CPUTAPID ] } {
adapter_nsrst_delay 100
jtag_ntrst_delay 100
-# LPC2000 - SRST causes TRST
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
--
1.6.5.1.1367.gcd48
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On Sat, Dec 4, 2010 at 10:47 PM, Freddie Chopin freddie_cho...@op.pl wrote: This is directly related to the findings from this post: https://lists.berlios.de/pipermail/openocd-development/2010-December/017405.html I've only removed srst_pulls_trst and comments that mentioned that (and comments that were not very helpful) Fred, I think the right place to define reset_config should be in files in board directory, not in target. The same target device could be present on many boards, with different circuit of JTAG connector. - We could have no connection for TRST signal (it is optional and in this case the TAP reset is obtained pulling down two signals together, don't remember which). - We could have no SRST (very common case, unfortunately) - We could have boards where SRST and TRST are connected together (I never found one, but...) Best Regards, Antonio Borneo ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
Here is my vision of this patch - with default value.
4\/3!!
From f573665d0ea4afbacff730c2591cf593374097b7 Mon Sep 17 00:00:00 2001
From: Rolf Meeser rolfm_...@yahoo.de
Date: Fri, 3 Dec 2010 14:10:40 +0100
Subject: [PATCH] lpc2478 target config: CCLK as (optional) parameter
Differences to original patch: CCLK is made optional, if not specified use 4MHz
default value.
Originally by: Rolf Meeser rolfm_...@yahoo.de
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
tcl/target/lpc2478.cfg |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/tcl/target/lpc2478.cfg b/tcl/target/lpc2478.cfg
index 99c8ce9..8cd65b2 100644
--- a/tcl/target/lpc2478.cfg
+++ b/tcl/target/lpc2478.cfg
@@ -12,6 +12,13 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0x4f1f0f0f
}
+if { [info exists CCLK ] } {
+ set _CCLK $CCLK
+} else {
+ set _CCLK 4000
+ echo Warning! You should specify the CCLK that will be used for flash
programming! Using default value of 4MHz.
+}
+
#delays on reset lines
adapter_nsrst_delay 100
jtag_ntrst_delay 100
@@ -37,7 +44,7 @@ $_TARGETNAME configure -event reset-init {
# After reset the chip uses its internal 4MHz RC oscillator.
# flash bank name lpc2000 base size 0 0 target# variant clock
[calc checksum]
set _FLASHNAME $_CHIPNAME.flash
-flash bank $_FLASHNAME lpc2000 0x0 0x7D000 0 0 $_TARGETNAME lpc2000_v2 4000
calc_checksum
+flash bank $_FLASHNAME lpc2000 0x0 0x7E000 0 0 $_TARGETNAME lpc2000_v2 $_CCLK
calc_checksum
# Try to use RCLK, if RCLK is not available use normal mode. 4MHz / 6 =
666kHz, so use 500.
jtag_rclk 500
--
1.6.5.1.1367.gcd48
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] iMX51 workaround
On Wednesday 01 December 2010 19:55:23 Øyvind Harboe wrote: On Wed, Dec 1, 2010 at 6:04 PM, Peter Stuge pe...@stuge.se wrote: Øyvind Harboe wrote: If iMX51 is broken and the current CortexA8 workaround code for it breaks other CPUs, then I think that the automatic workaround code for iMX51 has to be either fixed or removed. Do you know which commit it was added in? v0.4.0-570-g0649fb2 Marek did a whole bunch of great work solving other long standing problems. I don't mind testing patches for it. What's the breakage ? With what target / what are the symptoms etc? Cheers ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Automatic detection of debugbase for cortex A8
On Tuesday 30 November 2010 08:16:31 Øyvind Harboe wrote:
This patch breaks debugging on the DM37x. It appears that the debug
base and APID is not sufficient to identify problematic processors
since the DM37x on the Beagleboard XM incorrectly passes the checks in
arm_adi_v5.c:
for (i = 0; i sizeof(broken_cpus)/sizeof(struct broken_cpu);
i++) if (broken_cpus[i].dbgbase == dbgbase
broken_cpus[i].apid == apid) {
LOG_WARNING(Found broken CPU (%s), trying to
fixup ROM Table location from 0x%08x to 0x%08x,
broken_cpus[i].model, dbgbase,
broken_cpus[i].correct_dbgbase);
dbgbase = broken_cpus[i].correct_dbgbase;
break;
}
Is there another way that these problematic CPUs can be identified?
Anyone?
Ah I see it now ... I don't have DM37x based board, but I can try getting one.
Otherwise, can someone (with DM37x) help me fixing this ?
Thanks in advance, Cheers
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 04.12.2010 10:08, Freddie Chopin wrote: So you're all about correctness and you don't reset halt the chip before flashing? How is that correct? Actually flashing does not work if you don't reset halt the chip. The need for halting is obvious. The need for reset is not, but think about what would happen if your code would have a timer (or any) interrupt enabled and running during your flashing. Actually you DO need to get the chip in some known (and specific!) condition to flash it. I know what state the chip will be in - it is exactly the state which my startup code puts it into, so I can use the same state for flashing, without a need for an extra reset. I'm not telling slow down - I'm saying don't use this file that can speed things up because it also makes using OpenOCD a bit harder. Technically this file does not speed anything up, because there is no PLL setting anywhere in it - the new board config file (another patch) does speed things up and it can speed things up exactly the same way now or when lpc2478.cfg would use some default value. BTW why isn't the pll configuration function placed in target file? The PLL settings *do* belong in a board config file. The code that sets the PLL is not board-specific but CPU-specific, so it can be shared. If I'd have the microcontroller hooked up directly to JTAG and PSU with thin cables would that be considered a board too? It's just a simple microcontroller! It needs almost none configuration on OpenOCD's side - every board with LPC2478 was using the old file and it was fine. The term board refers to a CPU plus environment - even if you replace the physical board part with air. You need at least some decoupling capacitors, and you need to wire-up the JTAG connector, which can be done in different ways (regarding reset signals), so there are multiple possible setups that require different configurations. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming)
On 04/12/2010, at 7:43 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: How's this one coming? I'm happy with the previous set of patches I submitted (nov 30), it's been working well for me for the past couple of weeks with no issues. Andrew ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
