Re: [Mspgcc-users] msp430-gdbproxy loses connection with target
Back 100% on topic, William's (and other's) suggestions make total sense - if there is a known issue with rewriting the TxCTL register, why go there. Other than the initial setup of the TBCTL (which I'll get around to with a bit of embedded macro), I've gone and removed all instances where the TBCTL is rewritten, and used the dual read strategy to read the TBR (my TBR is incrementing every 250 odd uS, so substantially slower than the system clock). I left the logic running via the debugger last night, and as of this morning it's still happily ticking away. This is on the 439, where the longest I've seen without issues previously was the order of 10 minutes. I'm assuming this is all related to the same issue noted in the errata, but this only refers to the possibility of implicitly clearing the TxR if a MOV to the TxCTL is performed. What I have been seeing is rather more serious, where this appears to be corrupting something within the MSP itself, to the degree that the JTAG is no longer operational, and the MSP has to be power cycled to recover. This is particularly nasty because the loss of the JTAG effectively disables any ability to look inside with a debugger and isolate what is happening. In many ways it feels that it was pure luck that we stumbled across this - switching to the 4618 changed how the Timer B behaved, which led to the MOV issues with the TxCTL. Now that I feel we are getting some handle on this, I'll put a bit of effort into trying to isolate a simple scenario that demonstrates this. I'm surprised that this hasn't been noted previously, which makes me suspicious that there is still something else I am doing that could be contributing. Assuming that this can be isolated to the TxCTL MOV operations, where should I take this from here? It feels like something that should be noted in the errata. Thanks everyone for the help and suggestions. It definitely feels like a bright light at the end of a very long and dark tunnel! Andrew -Original Message- From: pabi...@gmail.com [mailto:pabi...@gmail.com] On Behalf Of Peter Bigot Sent: Friday, 20 September 2013 10:05 a.m. To: William Swanson Cc: Jesse Frey; GCC for MSP430 - http://mspgcc.sf.net; and...@aratika.co.nz Subject: Re: [Mspgcc-users] msp430-gdbproxy loses connection with target Yeah, this is pretty far from mspgcc, but still on topic for MSP430. There are three timer read solutions I use in BSP430, depending on the relative speed of the clocks: * If the clock source is synchronous to mclk, just read the counter. * If it's asynchronous and is significantly slower, read the counter repeatedly until two consecutive values are equal. * If it's asynchronous and is about the same speed or faster than MCLK dedicate a capture/compare register configured to capture both edges and keep CCIS1 set, then toggle CCIS0 in the CCTL register to latch the counter value. There's an amusing little gotcha in that last one: if the timer clock is slower than MCLK and you have SCS set, the captured count might not be correct (SCS delays the capture until the next falling edge of the timer clock). Take into account that sometimes you need to also record the CCTL value and know that it's consistent with the CCR value you select. For example, when trying to produce a 32-bit counter value you need to know whether an overflow has been recorded. My belief in the case of the two-consecutive-reads-that-match solution is that the CCTL value between the two reads will be correct; unfortunately the MSP430 user's guides don't give enough detail on exactly how the clock updates are done to guarantee that. And be careful about reading CCR from within an interrupt handler triggered by CCIFG, because if you use the IV interface the value you read might not be the one that triggered the interrupt (clearing CCIFG enables an overwrite of the captured value that would otherwise be signalled by the COV bit). http://pabigot.github.io/bsp430/timer_8h.html#h_periph_timer_hpl has some additional details. examples/platform/trxeb/timer_scs_test/main.c and examples/misc/syncap/main.c both demonstrate some of the edge cases of timer capture. On Thu, Sep 19, 2013 at 3:08 PM, William Swanson swanson...@gmail.com wrote: On Thu, Sep 19, 2013 at 12:44 PM, Jesse Frey jmf...@alaska.edu wrote: When I need to read a timer asynchronously do three consecutive reads and do a bitwize majority function on them. Not to take this thread too far off-topic, but that approach doesn't work. For example, say your middle reading happens to catch the timer just as it is rolling over from 0x to 0x. Your three readings would then be: 0x 0xff00 /* meta-stable transition state */ 0x Your bit-wise majority function would return 0xff00, which is still wrong. Since the whole point of taking multiple readings is to avoid these meta-stable transition states, a bit-wise majority isn't good enough. You need to compare whole values until you see two
Re: [Mspgcc-users] msp430-gdbproxy loses connection with target
On Thu, Sep 19, 2013 at 12:44 PM, Jesse Frey jmf...@alaska.edu wrote: When I need to read a timer asynchronously do three consecutive reads and do a bitwize majority function on them. Not to take this thread too far off-topic, but that approach doesn't work. For example, say your middle reading happens to catch the timer just as it is rolling over from 0x to 0x. Your three readings would then be: 0x 0xff00 /* meta-stable transition state */ 0x Your bit-wise majority function would return 0xff00, which is still wrong. Since the whole point of taking multiple readings is to avoid these meta-stable transition states, a bit-wise majority isn't good enough. You need to compare whole values until you see two that match. -William -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-gdbproxy loses connection with target
Yeah, this is pretty far from mspgcc, but still on topic for MSP430. There are three timer read solutions I use in BSP430, depending on the relative speed of the clocks: * If the clock source is synchronous to mclk, just read the counter. * If it's asynchronous and is significantly slower, read the counter repeatedly until two consecutive values are equal. * If it's asynchronous and is about the same speed or faster than MCLK dedicate a capture/compare register configured to capture both edges and keep CCIS1 set, then toggle CCIS0 in the CCTL register to latch the counter value. There's an amusing little gotcha in that last one: if the timer clock is slower than MCLK and you have SCS set, the captured count might not be correct (SCS delays the capture until the next falling edge of the timer clock). Take into account that sometimes you need to also record the CCTL value and know that it's consistent with the CCR value you select. For example, when trying to produce a 32-bit counter value you need to know whether an overflow has been recorded. My belief in the case of the two-consecutive-reads-that-match solution is that the CCTL value between the two reads will be correct; unfortunately the MSP430 user's guides don't give enough detail on exactly how the clock updates are done to guarantee that. And be careful about reading CCR from within an interrupt handler triggered by CCIFG, because if you use the IV interface the value you read might not be the one that triggered the interrupt (clearing CCIFG enables an overwrite of the captured value that would otherwise be signalled by the COV bit). http://pabigot.github.io/bsp430/timer_8h.html#h_periph_timer_hpl has some additional details. examples/platform/trxeb/timer_scs_test/main.c and examples/misc/syncap/main.c both demonstrate some of the edge cases of timer capture. On Thu, Sep 19, 2013 at 3:08 PM, William Swanson swanson...@gmail.comwrote: On Thu, Sep 19, 2013 at 12:44 PM, Jesse Frey jmf...@alaska.edu wrote: When I need to read a timer asynchronously do three consecutive reads and do a bitwize majority function on them. Not to take this thread too far off-topic, but that approach doesn't work. For example, say your middle reading happens to catch the timer just as it is rolling over from 0x to 0x. Your three readings would then be: 0x 0xff00 /* meta-stable transition state */ 0x Your bit-wise majority function would return 0xff00, which is still wrong. Since the whole point of taking multiple readings is to avoid these meta-stable transition states, a bit-wise majority isn't good enough. You need to compare whole values until you see two that match. -William -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-gdbproxy loses connection with target
MSP430FG4618 erratum TB18: MOV to TBCTL may clear TBR. http://www.ti.com/lit/er/slaz368c/slaz368c.pdf page 9. Peter On Tue, Sep 17, 2013 at 11:09 PM, Andrew McLaren and...@aratika.co.nzwrote: Just to close the loop on this, I think I have found the problem (or at least what the 439 MSP doesn't like). The logic maintains a reference timebase using the timer B module (this simply ticks away in the background and maintains a reference counter). To obtain a time reference at any time, the logic stops the timer block, reads the TBR, and restarts the timer block. Nothing really fancy there. It was a bit of luck, but the only other relatively large MSP I had available was the 4618 on an experimenters board. This also has a USART, so there were only minimal code changes needed between the 439 and the 4618 (the 4618 is a USART1 rather than a USART0, and that was pretty much it). However, the 4618 timer logic failed - when the timer was restarted, the TBR was cleared, whereas the 439 restarted (as expected) from where the TBR was stopped. This lead me to have a good look at how the timer block was stopped and restarted. To stop and restart the timer, the whole TBCTL was being rewritten, along the lines of; TBCTL = TBSSEL_1 | ID_3 | MC_0, and TBCTL = TBSSEL_1 | ID_3 | MC_2 This worked fine on the 439 (or at least appeared to work fine!). However stopping the timer block this way appeared to clear the TBR on the 4618, even though the TBCLR bit wasn't being set. To get this to work correctly on the 4618, I modified this to just touch the mode control bits, along the lines of; TBCTL = TBCTL ~MC0 ~MC1 TBCTL = (TBCTL ~MC0) | MC1 This resolved the timer issues with the 4618, which now ran the logic with no problems. Moreover, the logic functioned without any of the loss of connectivity with the JTAG seen with the 439. Just out of curiousity, I rebuilt the logic for the 439 and ran that again, and it also worked 100%. I could turn the JTAG connectivity issues on and off simply by how I was touching the TBCTL register. A bit more playing and looking at the full TBCTL before I modify it, the only difference between two two is that in the first case TBIFG is being cleared, whereas in the modified case this is being left at its set state. As I'm not using TBIE or TBIFG, this doesn't affect me at all. While the second TBCTL strategy is explicitly only touching what is required, so is probably better, I can't see why the initial strategy should have caused any issues (and also why it should have cleared the TBR on 4618, but luckily it did!). Its curiousity value now, but if anyone can give me any insights into why this has happened, I'd like to know! Thanks for the help and pointers in resolving this. Andrew -Original Message- From: Eric Decker [mailto:cire...@gmail.com] Sent: Tuesday, 3 September 2013 10:57 a.m. To: and...@aratika.co.nz Cc: Daniel Beer; GCC for MSP430 - http://mspgcc.sf.net Subject: Re: [Mspgcc-users] msp430-gdbproxy loses connection with target have you verified that the board is getting the voltage that you think it should be? On Mon, Sep 2, 2013 at 3:38 PM, Andrew McLaren and...@aratika.co.nz wrote: On Tue, Aug 27, 2013 at 10:40:45AM +1200, Andrew McLaren wrote: It would have been easy if the problem had been gdbproxy, but no such luck. Now that mspdebug is running, I'm seeing exactly the same scenario here. The messages are a tad different, but I think they are saying the same thing. Everything works fine until mspdebug reports... fet: FET returned error code 18 (Could not determine device state) fet: polling failed Once again, eveything appears hung outboard of mspdebug until the target msp is repowered. If I simply try and restart mspdebug without doing this, it will report; TI3410 device is in boot config, setting active ti3410: TI_OPEN_PORT failed: A device attached to the system is not functioning ti3410: failed to set up port This looks like some kind of hardware problem. Have you tried different USB ports? Is the board powered externally, or does it draw power from the FET? Cheers, Daniel I've been having a bit of a play to try and isolate it, but haven't come up with anything conclusive (or really anthing at all). To answer your questions - the target board is powered by the FET - I've tried switching USB ports, but no change. I've also tried switching the target processor (another 439), but also no change. The only harware I haven't yet swapped out is the FET itself, but only have the single TI FET running. I do have an Olimex FET here, but having a few issues at present installing the drivers for that, so that is the next step. The ONLY thing I have found so far that resets the problem is repowering the target MSP, which leads me to think that is must be some context in that that is somehow being corrupted. I'd also
Re: [Mspgcc-users] msp430-gdbproxy loses connection with target
I spoke too soon... Thanks for the pointer Peter. At least that could explain the implicit TBCLR. The code is in C so a I'm a little removed from the machine code the compiler produces. I had a peek at how its disassembled (the working C), and it moves the TBCTL into a register, manipulates that, then moves the complete register back to TBCTL. I've yet to compare this to the code originally produced, but I suspect C generated logic will always operate this way, rather than directly on the peripherals' registers. The erratum does say 'may'? Sadly, the underlying problem hasn't disappeared, just become rather more intermittent. It can now take hours to appear on the 4618, possibly less time on the 439, but its hard to be absolute. All I am certain about is that something in my logic is upsetting the MSP, but once it happens I've lost connectivity with the MSP to be able to isolate it. Eric earlier made a comment re the board voltages, so while I've had the experimenters board running, I took the opportunity of powering this locally rather than via the FET, but no change in outcome. I also ran the logic disconnected from the FET overnight (its running an RF heartbeat, so could keep some track that it was still alive), and this also failed after a number of hours, so whatever is wrong (assuming its the same thing) is not just upsetting the JTAG interface. I'm back to the drawing board! Andrew -Original Message- From: pabi...@gmail.com [mailto:pabi...@gmail.com] On Behalf Of Peter Bigot Sent: Wednesday, 18 September 2013 10:15 p.m. To: and...@aratika.co.nz Cc: Eric Decker; GCC for MSP430 - http://mspgcc.sf.net Subject: Re: [Mspgcc-users] msp430-gdbproxy loses connection with target MSP430FG4618 erratum TB18: MOV to TBCTL may clear TBR. http://www.ti.com/lit/er/slaz368c/slaz368c.pdf page 9. Peter On Tue, Sep 17, 2013 at 11:09 PM, Andrew McLaren and...@aratika.co.nz wrote: Just to close the loop on this, I think I have found the problem (or at least what the 439 MSP doesn't like). The logic maintains a reference timebase using the timer B module (this simply ticks away in the background and maintains a reference counter). To obtain a time reference at any time, the logic stops the timer block, reads the TBR, and restarts the timer block. Nothing really fancy there. It was a bit of luck, but the only other relatively large MSP I had available was the 4618 on an experimenters board. This also has a USART, so there were only minimal code changes needed between the 439 and the 4618 (the 4618 is a USART1 rather than a USART0, and that was pretty much it). However, the 4618 timer logic failed - when the timer was restarted, the TBR was cleared, whereas the 439 restarted (as expected) from where the TBR was stopped. This lead me to have a good look at how the timer block was stopped and restarted. To stop and restart the timer, the whole TBCTL was being rewritten, along the lines of; TBCTL = TBSSEL_1 | ID_3 | MC_0, and TBCTL = TBSSEL_1 | ID_3 | MC_2 This worked fine on the 439 (or at least appeared to work fine!). However stopping the timer block this way appeared to clear the TBR on the 4618, even though the TBCLR bit wasn't being set. To get this to work correctly on the 4618, I modified this to just touch the mode control bits, along the lines of; TBCTL = TBCTL ~MC0 ~MC1 TBCTL = (TBCTL ~MC0) | MC1 This resolved the timer issues with the 4618, which now ran the logic with no problems. Moreover, the logic functioned without any of the loss of connectivity with the JTAG seen with the 439. Just out of curiousity, I rebuilt the logic for the 439 and ran that again, and it also worked 100%. I could turn the JTAG connectivity issues on and off simply by how I was touching the TBCTL register. A bit more playing and looking at the full TBCTL before I modify it, the only difference between two two is that in the first case TBIFG is being cleared, whereas in the modified case this is being left at its set state. As I'm not using TBIE or TBIFG, this doesn't affect me at all. While the second TBCTL strategy is explicitly only touching what is required, so is probably better, I can't see why the initial strategy should have caused any issues (and also why it should have cleared the TBR on 4618, but luckily it did!). Its curiousity value now, but if anyone can give me any insights into why this has happened, I'd like to know! Thanks for the help and pointers in resolving this. Andrew -Original Message- From: Eric Decker [mailto:cire...@gmail.com] Sent: Tuesday, 3 September 2013 10:57 a.m. To: and...@aratika.co.nz Cc: Daniel Beer; GCC for MSP430 - http://mspgcc.sf.net Subject: Re: [Mspgcc-users] msp430-gdbproxy loses connection with target have you verified that the board is getting the voltage that you think it should be? On Mon, Sep 2, 2013 at 3:38 PM, Andrew McLaren and...@aratika.co.nz wrote: On Tue, Aug 27, 2013 at 10:40:45AM +1200, Andrew McLaren wrote: It would
Re: [Mspgcc-users] msp430-gdbproxy loses connection with target
Just to close the loop on this, I think I have found the problem (or at least what the 439 MSP doesn't like). The logic maintains a reference timebase using the timer B module (this simply ticks away in the background and maintains a reference counter). To obtain a time reference at any time, the logic stops the timer block, reads the TBR, and restarts the timer block. Nothing really fancy there. It was a bit of luck, but the only other relatively large MSP I had available was the 4618 on an experimenters board. This also has a USART, so there were only minimal code changes needed between the 439 and the 4618 (the 4618 is a USART1 rather than a USART0, and that was pretty much it). However, the 4618 timer logic failed - when the timer was restarted, the TBR was cleared, whereas the 439 restarted (as expected) from where the TBR was stopped. This lead me to have a good look at how the timer block was stopped and restarted. To stop and restart the timer, the whole TBCTL was being rewritten, along the lines of; TBCTL = TBSSEL_1 | ID_3 | MC_0, and TBCTL = TBSSEL_1 | ID_3 | MC_2 This worked fine on the 439 (or at least appeared to work fine!). However stopping the timer block this way appeared to clear the TBR on the 4618, even though the TBCLR bit wasn't being set. To get this to work correctly on the 4618, I modified this to just touch the mode control bits, along the lines of; TBCTL = TBCTL ~MC0 ~MC1 TBCTL = (TBCTL ~MC0) | MC1 This resolved the timer issues with the 4618, which now ran the logic with no problems. Moreover, the logic functioned without any of the loss of connectivity with the JTAG seen with the 439. Just out of curiousity, I rebuilt the logic for the 439 and ran that again, and it also worked 100%. I could turn the JTAG connectivity issues on and off simply by how I was touching the TBCTL register. A bit more playing and looking at the full TBCTL before I modify it, the only difference between two two is that in the first case TBIFG is being cleared, whereas in the modified case this is being left at its set state. As I'm not using TBIE or TBIFG, this doesn't affect me at all. While the second TBCTL strategy is explicitly only touching what is required, so is probably better, I can't see why the initial strategy should have caused any issues (and also why it should have cleared the TBR on 4618, but luckily it did!). Its curiousity value now, but if anyone can give me any insights into why this has happened, I'd like to know! Thanks for the help and pointers in resolving this. Andrew -Original Message- From: Eric Decker [mailto:cire...@gmail.com] Sent: Tuesday, 3 September 2013 10:57 a.m. To: and...@aratika.co.nz Cc: Daniel Beer; GCC for MSP430 - http://mspgcc.sf.net Subject: Re: [Mspgcc-users] msp430-gdbproxy loses connection with target have you verified that the board is getting the voltage that you think it should be? On Mon, Sep 2, 2013 at 3:38 PM, Andrew McLaren and...@aratika.co.nz wrote: On Tue, Aug 27, 2013 at 10:40:45AM +1200, Andrew McLaren wrote: It would have been easy if the problem had been gdbproxy, but no such luck. Now that mspdebug is running, I'm seeing exactly the same scenario here. The messages are a tad different, but I think they are saying the same thing. Everything works fine until mspdebug reports... fet: FET returned error code 18 (Could not determine device state) fet: polling failed Once again, eveything appears hung outboard of mspdebug until the target msp is repowered. If I simply try and restart mspdebug without doing this, it will report; TI3410 device is in boot config, setting active ti3410: TI_OPEN_PORT failed: A device attached to the system is not functioning ti3410: failed to set up port This looks like some kind of hardware problem. Have you tried different USB ports? Is the board powered externally, or does it draw power from the FET? Cheers, Daniel I've been having a bit of a play to try and isolate it, but haven't come up with anything conclusive (or really anthing at all). To answer your questions - the target board is powered by the FET - I've tried switching USB ports, but no change. I've also tried switching the target processor (another 439), but also no change. The only harware I haven't yet swapped out is the FET itself, but only have the single TI FET running. I do have an Olimex FET here, but having a few issues at present installing the drivers for that, so that is the next step. The ONLY thing I have found so far that resets the problem is repowering the target MSP, which leads me to think that is must be some context in that that is somehow being corrupted. I'd also like to try a different MSP variant, but none of the others I have here have the ROM space this needs (just thinking, I do have one of the TI experimeter boards around, and that has a fairly hefty MSP on it, so that could be worth a go). So I have a couple of things to try. I'll keep you
Re: [Mspgcc-users] msp430-gdbproxy loses connection with target
On Tue, Aug 27, 2013 at 10:40:45AM +1200, Andrew McLaren wrote: It would have been easy if the problem had been gdbproxy, but no such luck. Now that mspdebug is running, I'm seeing exactly the same scenario here. The messages are a tad different, but I think they are saying the same thing. Everything works fine until mspdebug reports... fet: FET returned error code 18 (Could not determine device state) fet: polling failed Once again, eveything appears hung outboard of mspdebug until the target msp is repowered. If I simply try and restart mspdebug without doing this, it will report; TI3410 device is in boot config, setting active ti3410: TI_OPEN_PORT failed: A device attached to the system is not functioning ti3410: failed to set up port This looks like some kind of hardware problem. Have you tried different USB ports? Is the board powered externally, or does it draw power from the FET? Cheers, Daniel I've been having a bit of a play to try and isolate it, but haven't come up with anything conclusive (or really anthing at all). To answer your questions - the target board is powered by the FET - I've tried switching USB ports, but no change. I've also tried switching the target processor (another 439), but also no change. The only harware I haven't yet swapped out is the FET itself, but only have the single TI FET running. I do have an Olimex FET here, but having a few issues at present installing the drivers for that, so that is the next step. The ONLY thing I have found so far that resets the problem is repowering the target MSP, which leads me to think that is must be some context in that that is somehow being corrupted. I'd also like to try a different MSP variant, but none of the others I have here have the ROM space this needs (just thinking, I do have one of the TI experimeter boards around, and that has a fairly hefty MSP on it, so that could be worth a go). So I have a couple of things to try. I'll keep you posted. Andrew -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-gdbproxy loses connection with target
have you verified that the board is getting the voltage that you think it should be? On Mon, Sep 2, 2013 at 3:38 PM, Andrew McLaren and...@aratika.co.nz wrote: On Tue, Aug 27, 2013 at 10:40:45AM +1200, Andrew McLaren wrote: It would have been easy if the problem had been gdbproxy, but no such luck. Now that mspdebug is running, I'm seeing exactly the same scenario here. The messages are a tad different, but I think they are saying the same thing. Everything works fine until mspdebug reports... fet: FET returned error code 18 (Could not determine device state) fet: polling failed Once again, eveything appears hung outboard of mspdebug until the target msp is repowered. If I simply try and restart mspdebug without doing this, it will report; TI3410 device is in boot config, setting active ti3410: TI_OPEN_PORT failed: A device attached to the system is not functioning ti3410: failed to set up port This looks like some kind of hardware problem. Have you tried different USB ports? Is the board powered externally, or does it draw power from the FET? Cheers, Daniel I've been having a bit of a play to try and isolate it, but haven't come up with anything conclusive (or really anthing at all). To answer your questions - the target board is powered by the FET - I've tried switching USB ports, but no change. I've also tried switching the target processor (another 439), but also no change. The only harware I haven't yet swapped out is the FET itself, but only have the single TI FET running. I do have an Olimex FET here, but having a few issues at present installing the drivers for that, so that is the next step. The ONLY thing I have found so far that resets the problem is repowering the target MSP, which leads me to think that is must be some context in that that is somehow being corrupted. I'd also like to try a different MSP variant, but none of the others I have here have the ROM space this needs (just thinking, I do have one of the TI experimeter boards around, and that has a fairly hefty MSP on it, so that could be worth a go). So I have a couple of things to try. I'll keep you posted. Andrew -- Eric B. Decker Senior (over 50 :-) Researcher -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-gdbproxy loses connection with target
It would have been easy if the problem had been gdbproxy, but no such luck. Now that mspdebug is running, I'm seeing exactly the same scenario here. The messages are a tad different, but I think they are saying the same thing. Everything works fine until mspdebug reports... fet: FET returned error code 18 (Could not determine device state) fet: polling failed Once again, eveything appears hung outboard of mspdebug until the target msp is repowered. If I simply try and restart mspdebug without doing this, it will report; TI3410 device is in boot config, setting active ti3410: TI_OPEN_PORT failed: A device attached to the system is not functioning ti3410: failed to set up port Any ideas? Andrew No reason at all except maybe laziness. I did have a play with mspdebug a few years back, and from memory had some issues with the target processor I was using. gdbproxy worked, so I've stayed with that ever since. There is always enough work in the code itself, so if the environment works I just tend to leave it alone. I wasn't aware there was any formal plans to deprecate gdbproxy, but was aware of a lot of the development/support discusssions around this. I'm in the process of reinstalling mspdebug, so we'll see if that makes any difference. I'll let you know! Thanks - Andrew -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-gdbproxy loses connection with target
On Tue, Aug 27, 2013 at 10:40:45AM +1200, Andrew McLaren wrote: It would have been easy if the problem had been gdbproxy, but no such luck. Now that mspdebug is running, I'm seeing exactly the same scenario here. The messages are a tad different, but I think they are saying the same thing. Everything works fine until mspdebug reports... fet: FET returned error code 18 (Could not determine device state) fet: polling failed Once again, eveything appears hung outboard of mspdebug until the target msp is repowered. If I simply try and restart mspdebug without doing this, it will report; TI3410 device is in boot config, setting active ti3410: TI_OPEN_PORT failed: A device attached to the system is not functioning ti3410: failed to set up port This looks like some kind of hardware problem. Have you tried different USB ports? Is the board powered externally, or does it draw power from the FET? Cheers, Daniel -- Daniel Beer dlb...@gmail.comwww.dlbeer.co.nz IRC: inittab (Freenode)PGP key: 2048D/160A553B -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-gdbproxy loses connection with target
is there some reason you are using msp430-gdbproxy rather than mspdebug? msp430-gdbproxy has been deprecated for many years now. current devlopment is occuring on mspdebug. it is a superset of msp430-gdbproxy. On Sat, Aug 24, 2013 at 6:16 PM, Andrew McLaren and...@aratika.co.nzwrote: I've been struggling with an (almost) repeatable issue with gdpproxy losing connection with the target msp. After operating correctly for a period, gdbproxy will suddenly report error: msp430: Could not determine device state (18) in response to an MSP430_State() request by gdbproxy. then following this a stream of error: msp430: No error (0) in response to a sequence of MSP430_Memory(READ) requests. At this point I've only been able to get this working again by repowering the FET and the target msp (actually the target msp looks like its enough, but its typically powered via the FET). From this I'm guessing that something in the logic being debugged is corrupting the target msp's JTAG interface in some way, which effectively disrupts communication with the FET. Repowering the target msp resets all the interfaces to a known state, which gets things back in line. However, even if this is the case, I'm not having much luck isolating where this is happening, and hoping someone can give me some ideas or pointers which may help in isolating this. When I said 'almost' above, often this seems to trigger in the same sequence in the logic, but not always, so its not totally predictable. I've been trying to 'binary chop' the logic from where it is known good to where it is often bad, but the lack of predicatability is running me in circles. I've also forced the code to link in a different order (theory being that if it was a relative addressing rather than absolute addressing issue, the problem would move), but its remained much the same (but of course the lack of predicatability means I can't be certain!) Where it is occuring it should be running logic that has all previously been exercised a number of times. - Does my diagnosis sound right, or at least reasonable? - From what I can glean, the target msp (a 439) has a dedicated JTAG interface, and can't see that any of this is configurable, even inadvertently. Am I missing something here, or is there some other way the JTAG interface can be impacted? - Any other ideas for what could cause this? - Any ideas or techniques for isolating this sort of problem. The setup is Eclipse talking to the target MSP (a 439) via msp430-gdbproxy (version 0.7.1), and a TI USB FET. Thanks for any thoughts. Andrew -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Eric B. Decker Senior (over 50 :-) Researcher -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-gdbproxy loses connection with target
No reason at all except maybe laziness. I did have a play with mspdebug a few years back, and from memory had some issues with the target processor I was using. gdbproxy worked, so I've stayed with that ever since. There is always enough work in the code itself, so if the environment works I just tend to leave it alone. I wasn't aware there was any formal plans to deprecate gdbproxy, but was aware of a lot of the development/support discusssions around this. I'm in the process of reinstalling mspdebug, so we'll see if that makes any difference. I'll let you know! Thanks - Andrew -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
