Jump to content
43oh

tripwire

Members
  • Content Count

    193
  • Joined

  • Last visited

  • Days Won

    14

Everything posted by tripwire

  1. Ah, I guess the debugger's using the RST line for JTAG comms, so that stops S1 from working until you disconnect... What happens if you pull the USB cable during debugging, then exit the debugger and plug the USB back in? Additionally, try another test run but pulling the cable after disconnecting the debugger. To be honest I'm just clutching at straws here, I can't think of anything that would cause the symptoms you're getting. If you don't mind sharing your code, I'd be happy to try it out and see if I can get the same issue to occur on my kit. (BTW, it's probably best to attach
  2. This is an interesting puzzle! (though probably infuriating for the OP...) MRose, what happens if you reset the launchpad by pressing S1? Try this with the debugger attached while it's running at the right speed and also just after disconnect. Does it run with the 1 second delay like it's supposed to after resetting in both cases?
  3. The JSF's pretty heavy on software as far as I know. I recently stumbled on this interesting bit of trivia about it - not only is the JSF's software written in C++, but they got Bjarne Stroustrup to work on the coding standards document! Here's the document in all it's sleep-inducing glory ;-): www.stroustrup.com/JSF-AV-rules.pdf And here's a presentation giving the overview of why they chose C++ and how they went about trying to make it safe: www.phaedsys.com/principals/programmingresearch/prdata/SSE-Session-4_Stroustrup-Carroll.pdf EDIT: As for the "10,000 lines of code", I th
  4. Hi, Since I started programming for MSP430 I've been looking for the MSP equivalent of "__asm int 3" (aka DebugBreak). I've come up with this fragment, tested on CCS 5.3.0: #ifndef NDEBUG // If debugger is attached and software breakpoints are enabled, DEBUG_BREAK will pause execution #define DEBUG_BREAK _op_code(0x4343) #else // Strip out DEBUG_BREAKs in final/release builds #define DEBUG_BREAK #endif Put this in a header file and you can then embed breakpoints in your code with a DEBUG_BREAK; statement. To reiterate what it says in the comment above: DEBUG_BREAK onl
  5. Hi, Although I don't program 430's in assembly (yet ;-)) I was particularly interested in this post about naken430asm in the tips section. Naken430util's disassembly listing with per-instruction cycle counts looked like a useful optimisation tool, and a good way to keep tabs on the compiler. I tried it out and liked it so much that I wanted to integrate it into my future CCS projects as standard. After poking around in the CCS install folder and reading TI's instructions I managed to make a plugin that adds a new project template. It's based on the standard "Empty project with main.c"
  6. I just spotted the post in tips about Larissa Swanland's TI University video. It looks like the video URL changed after you posted, it's now at: (It's surprisingly tricky to post youtube links without embedding on this board software. Code tags to the rescue! )
  7. Hi, It took me a while to figure this out myself. What's supposed to happen is that pressing the button reads the current temperature and that is then used as a reference. If the chip gets hotter the red led comes on and brightens as the difference between the reference and current temperature increases. If the chip gets cooler the green led behaves likewise. You can press the button again to recapture the reference temperature. Just putting your finger on top of the chip may not be enough to make a big difference to the temperature. Rubbing your finger on something to heat it up a bit
  8. Thanks! I'll give it a go later on today, see what happens
  9. Just to check, is it OK to leave the 47k pulldown resistor on TEST during programming? I'm hoping the launchpad's emulation board will be still able to drive the TEST pin up as required despite the pulldown. Thanks
  10. Hi, Thanks to the tips on 43oh.com I just managed to use my launchpad to program a 2553 on a breadboard. My code deployed fine and ran without issues, but I noticed something slightly different when I was finished testing. The chip stopped running the code as soon as I terminated the debug session. Normally, when the debugger is connected to a chip on the launchpad's emulation section, terminating just detaches the debugger. Assuming the debugger wasn't paused or on a breakpoint the chip continues to run the code uploaded to it. Could I have done something on my breadboard that
  11. And I've found a solution - ignore the bit of BCL12 that says if RSEL is 15 you should drop it to 7 before modifying DCOCTL (this advice conflicts with that in the user guide). By following the BCL12 advice I had one chip out of four fail after clock setup. Following the user guide (as posted by Rickta59 and roadrunner84 above) caused no failures.
  12. I'm working on a program that measures the DCO clock frequency for all valid combinations of RSEL, DCO and MOD bits. It works fine on two chips I've tried it on (a 2553 and a 2001), but fails when I try it on my 2452. I suspect it's just down to tolerances in the chip, so most will work fine. The problem occurs when trying to reach the higher DCOCTL settings with RSEL set to 15. Following the old BCL12 advice I was able to reach DCOCTL = 0xCF, BCSCTL1 = 0x8F, but going any higher caused a hang. The new advice lets me reach DCOCTL = 0xD7, but it should be possible to go all the way up
  13. Hi Oliveira, oPossum's uint32hex function is indeed a good way to convert a number to a hex string, but I've been looking at your code and it doesn't appear that you need to do this. As cubeberg said: "The int value itself isn't specifically decimal or hex - those are just ways of displaying a certain value." If I have a function like this: void test(int i) { // insert code here... } I can call it in any of these ways: test(12345); // decimal integer literal test(0x3039); // hexadecimal integer literal test(030071); // octal integer literal (!) int number = someFunctionThat
  14. I added some delays to the RSEL stepping loop, but it didn't help. As I was testing the change I realised that I've been stepping through the code in the debugger anyway, which gives the DCO more than enough time to settle. I also tried clocking the CPU with VLO during the DCO setup. This allowed the CPU to continue running past the instruction that was previously killing it (setting RSEL to 15). Unfortunately when I then tried to switch the CPU back to DCO it hung. It looks like the bug might cause the DCO to completely stop oscillating if you're really unlucky.
  15. Having said that, maybe you're right and I do need to wait between steps so the DCO can settle. I tried the updated workaround on a problematic chip last night, and while it improved matters it didn't fully resolve the issue. I'll see if adding some delay cycles to my RSEL-stepping loop helps any.
  16. This is for the DCO, so there's no flag to wait for - AFAIK only the crystal oscillator has a fault flag. Normally the DCO is what's clocking the CPU, so I think changing the DCO settings makes the CPU pause until the DCO is stable. At least, that's what it does when restarting the DCO after LPM. As for the effect on code size, I'm wondering whether the new advice actually simplifies things. If you just use a loop to step RSEL to the desired value then you never need worry about rules 1 and 2. On startup, rule 3 can be avoided if you set DCOCTL before ramping RSEL up to 15 (if that's what
  17. Hi, I'm not sure which erratum you're describing there. BCL12 used to be: 1) If changing RSEL from >13 to <=12, switch to 13 first 2) If changing RSEL from <=12 to >13, switch to 7 first 3) If changing DCOCTL when RSEL is 15, set RSEL to 7, modify DCOCTL and then reset RSEL to 15 The updated version says that these original rules fix most cases, but a more reliable method is to always change RSEL step-by-step. By that I think they mean increment or decrement RSEL by 1 until you reach the target value.
  18. Hi guys, I just noticed that the errata files for the value line were updated on 17th January. The new files contain a revision to the BCL12 text, adding the following advice: "In the majority of cases switching directly to intermediate RSEL steps as described above will prevent the occurrence of BCL12. However, a more reliable method can be implemented by changing the RSEL bits step by step in order to guarantee safe function without any dead time of the DCO." Might be of interest if you've been getting DCO lockups as I have recently!
×
×
  • Create New...