stube40

Yes, that was it. Low power mode was doing it. I turned it off and it all works sweet now. However, that raises another question - how can you talk to a device that is spending most of it's time in low power mode? I guess you cant..............

OK, so I made sure the EP had Rx on using the IOCTL command you gave, but still no joy. I'm definitely getting EP Tx'd messages Rx'd by the AP, but just not the other way. Since my code is based on the TI Energy Harvest demo, the AP is polling for received messages whilst the EP is just transmitting once per second and sleeping in between transmits. Could this be related?? What I do is have the AP immediately send a message back to the EP when it receives a message from the EP - thus the EP is dictating the timing here. Of course, based on this timing the EP will always be asleep w

Awesome guys!! Thanks for the help. Will make the changes and report back.

I've adapted the Energy Harvest demo for a project so that I now have a start-network in which all my EndPoints can send data to the AccessPoint, where it is then sent to the virtual COM port and captured by a MS Visual Studio application which reads the COM port. So far so good......... However, I now have the requirement to send some simple messages from the AccessPoint to each individual EndPoint but cannot get it to work. Suppose I have 2x EndPoints in the network, then the SMPL_LinkListen function in the AccessPoint will be successful twice, giving me address handles of 0x01 and 0

Ha ha - yes, makes perfect sense! I was thinking it was some register somewhere and/or a compiler setting.

Thanks everyone! Glad I asked since it's obviously not a clear-cut as I though it might be. But, just to summarise - nested interrupts are possible with the MSP430 but, by default, they are not enabled. Thus, there is no need to turn interrupts on/off inside an interrupt service routine. This just begs one more question - how do you turn nesting on? If you actually wanted nested interrupts, how would you make it happen? Not that I want to, but I'm intrigued and it's useful background information in the unlikely event that interrupt nesting is actually required in some project.

OK, thanks alot RobG - that was what I thought, but it's good to know 100%.

My interrupt service routines generally look like this: #pragma vector = PORT1_VECTOR __interrupt void PORT1_ISR(void) { __disable_interrupt(); // Disable global INTs so nothing can interrupt this ISR // General content of ISR __enable_interrupt(); // Re-enable global INTs } I was wondering - is it necessary to manually disable/enable interrupts as I currently do, or does IAR automatically look after this for you when it compiles hence making my calls to __disable_interrupt() and __enable_interrupt() redundant?

@nobody - I hadn't spotted the voltage/frequency dependence you pointed out on page 26. Thanks for that!! If I am reading it correctly though, it suggests that I can't drop much below 3.3V at my configured speed of 16MHz. Is that really true, or am I mis-understanding it? I loved your suggestion about removing caps on the switched part of the power bus - surprise, surprise, I have a 10uF right next to the switching FET (on the switched side of the I2C bus). I might temporarily remove this and see what difference it makes.

OK, I modded the board to that the reset-line (pin 5) is now pulled up via 47k. Unfortunately this didn't help the problem I'm currently having. I put a scope on Vcc and found that it is dropping to 2.5V when I switch the I2C rail on (ie when the reset problem happens). I haven't found the part in the data sheet which tells you how low Vcc can go, but I'm thinking it must be at least 2.2V. Hence, could this be a brown-out issue? Also, I declared traps for all unhandled interrupt vectors in case it was something to do with this, but I had issues compiling the reset vector. When I compil

@oPossum - this forum wont let me post off-site URLs yet as I'm a new user (spam protection). I tried to add my circuit diagram and PCB but it wouldn't let me post the links to the pictures on photobucket, hence I will describe it for now (ban should be lifted soon). C20 and C21 are right next to the chip. They are 100nFs. This is all I have. Is this sufficient, or does it need additional caps? I will look into unhandled interrupt vectors and report back. @Sugar Addict - I use pin 5 as TDIO which plugs straight into the 6-pin connector on the USB debugger of the evaluation kit (the pin

I'm trying to debug a weird issue by where my firmware resets itself - that is, it returns to the first line of assembler code labelled 'cstart_begin' in the disassembly. If I put a breakpoint on the line of assembler code previous to cstart_begin, it never fires - hence it must be jumping to here. To shed a bit more light on this, I have my own custom hardware PCB with a few chips hanging off the I2C bus. These I2C chips have a power rail which can be switched on/off via a MOSFET controlled by a single bit on PORT3 of the CPU. It's when I'm switching the I2C rail ON that the resets ha