MSP430f6436
I just wanted to know, if the micro controller will go into Low power state (LPM3.5) if we cut the main power supply of the micro controller?
Backup battery is already connected with the internal RTC. And while the RTC is in operation the RTC is active.
According to the User Guide,
LPMx.5 entry and exit is handled differently than the other low power
modes. LPMx.5, when used properly, gives the lowest power consumption
available on a device. To achieve this, entry to LPMx.5 disables the
LDO of the PMM module, removing the supply voltage from the core of
the device.
Further, the way to enter this LPM3.5 mode is also described very well in the UG
The program flow for entering LPMx.5 is: 1. Configure I/O
appropriately. See the Digital I/O chapter for complete details on
configuring I/O for LPMx.5.
• Set all ports to general purpose I/O.
Configure each port to ensure no floating inputs based on the
application requirements.
• If wakeup from I/O is desired, configure
input ports with interrupt capability appropriately.
2. If LPM3.5 is available, and desired, enable RTC operation. In addition, configure any RTC interrupts, if desired for LPM3.5 wakeup
event. See the RTC Overview chapter for complete details.
3. Ensure clock system settings allow LPMx.5 entry according to Table 5-1 in UCS chapter.
4. Enter LPMx.5 by setting PMMREGOFF=1 and LPM4 status register bits. The following code example shows how to enter LPMx.5 mode. See the PMM
chapter for further details.
Broadly speaking what these two paragraphs mean, is that some amount of SW intervention is required to enter the LMP3.5 mode.
"Cutting" the main power supply to the micro controller will not perform these operations for you, unless it is still possible (i.e. the ramp down is long enough) to capture and handle those events via Low-Side Supervisor (SVSL) and Low-Side Monitor (SVML) interrupts.
Related
As you probably guessed this question is not about a programming language but about arduino.
I'm making a big project which includes a GSM SIM900A module but it draws too much power.
I've looked up the datasheet but I didn't understand a lot as it references a DTR pin, something my module doesn't have.
Can someone tell me how to put it to sleep mode?
Any help will be grately appreciated!
Thanks in advance!
The GSM standard AT command for the setting of modem's level of functionality is AT+CFUN.
According to SIM900 AT commands guide its syntax is
AT+CFUN=fun[,rst]
Where:
fun: is the power saving mode
rst: is the reset flag
There are several possible values of fun parameter that can be supported or not depending on the modem vendor.
In order to reduce power consumption, SIM900A offers two possibilities:
AT+CFUN=0, means that the device is in sleep mode, and the AT interface is not accessible. Usually it keeps its network paging activities and its registration status to the network (it's not really clear from SIM900 guide). The device is woken up as soon as a wake up event occurs (for example an incoming SMS). Test it on your device.
AT+CFUN=4, that disable both TX and RX RF circuits. The AT interface remains reachable.
Usually first solution results in a bigger reduction of power consumption, but I suggest trying both of them in your specific board in order to understand what is the better choice for you.
Most, if not all, microcontrollers have a vector table for all the exceptions that are encountered when the program is running. I am quite confused as to whether the bootloader also has its own vector table for executing the reset handler?
I have written a bootloader that has been ported between a number of different embedded processors used within comms products (MSP430, AVR32, DSP56300). This loader had quite limited functional requirements
Hardware initialisation.
Validate the main code image using a checksum or cryptographic signature.
Transfer of control to the main application if the validation passes.
Provide a minimal command interface over a serial port to allow for firmware update.
Reentry point to allow the main application to trigger a new firmware load.
This transfer of operation between the two programmes held in non volatile memory on the same processor meant that I had to provide a re-direction of the interrupt functions between the two completely separate applications. The Interrupt table for the MSP430 is held in FLASH and so cannot be modified easily. It also holds the reset vector that must always point to the start of the bootloader code so erasing and rewriting this area runs the risk of completely bricking the unit.
The solution in this case was to have an interrupt service routine in the bootloader that redirected through a vector table located at a fixed location within the application memory space. Using this method added one indirect jump instruction to each interrupt handler resulting in a minimal extra processor load for each interrupt that is processed. The bootloader was written to not use any interrupts relying on polling the serial port status for all of the communications. If the bootloader needed to use interrupts then the vector table can be moved to RAM and initialised by the bootloader or application as required. (My processor did not have enough RAM to allow this)
There was a simple data structure at a fixed location in the main application code that contained entries for each possible interrupt/exception and the start address of the application code (you could consider this as the application code reset vector). As long as the application provided this data structure in flash and correctly populated it could be compiled and build completely separately as if it was the only application on the processor.
A bootloader is just a program there is no magic there, as with any other program if it needs a vector table the programmers create a vector table. Certainly if it needs to run from reset then it must conform to the hardware/processor rules for that. The processor nor any of the other logic has any way to know that that collection of bits, that collection of instructions is a bootloader or not. It just runs it.
I assume you are talking about the many, but not all, flavors/brands of microcontrollers that have bootloaders programmed at the factory?
Within an mcu there is a processor core with a memory bus. The many items in the chip, ram, flash, gpio, spi, timer, uart, adc, etc all live on that bus like having more than one house on a particular street. Each of these items on the processor bus have address decoders looking for their address on the bus to know when to take or provide data/information. The application flash and bootloader rom are no different, not special. As easy as it is to do in software it is as easy in hardware to have some sort of if-then-else that allows the application flash to answer the processor at the vector table addresses, that flag that drives the then or else cases can be an input pin to the part. Tie the pin high and hit the reset and the part boots from one memory, tie the pin low hit the reset and the part boots from the other. There are other solutions out there that are perhaps not driven by an input pin to the part but by the bootloader software.
Sometimes the processor core itself has a signal that the chip vendor drives however it wants, that within the processor core it does an if-then else, perhaps the then case is 0x00000000 is where it looks for the vector table, and the else case 0xFFFF0000.
At the end of the day though a bootloader is just another program, written by someone for this chip, no different than the program you write for the chip other than the fact that if it is a factory programmed rom bootloader then the programmer for that bootloader might have additional information/documentation for that part that we dont have. But being a bootloader is not magic it is just a program, a collection of instructions. our application can be a bootloader as well, with several possible different applicaitons based on what our bootloader finds, their bootloader can boot our bootloader which then chooses from several applications and runs one of them. All within one part...
I tried looking everywhere to understand how BLE pairing works but unable to find answers. Lets say I have a small device, like a raspberry pi with a BLE dongle. What I'd like to do is to allow BLE pairing and then subsequent communication with a BLE peripheral (such as a BLE temperature sensor) using software only.
My aim is to try and see if I can control the pairing and then getting the temperature, without touching the sensor at all, so that in future, I can just remotely log into the raspberry pi, turn on bluetooth, obtain the temperature reading and then afterwards turn it off again. And in future if I need to obtain the reading again, I'll repeat the process.
So:
Can this "simple" scenario be achieved using some software based control?
If not, then which parts require manual input and then which don't?
The BLE sensor should not be in advertisement mode or broadcasting the information. It should only send the data to paired devices.
Any and all answers appreciated! :-)
Most Bluetooth low energy devices do not require pairing at all so check first that your sensors do have this requirement. If they do then you need to determine which specific pairing procedure is required. Bluetooth defines various ways to authenticate during pairing and these generally relate to the I/O capabilities of the two devices and are called Association Models. In some cases, pairing "just works" (the name of the simplest association model) and no user interaction is required. In others, say if one device has a keyboard but the other has a display and no keyboard, the second device will display a random 6 digit number and the user must key that number into the first device. All of this is defined in the Bluetooth Core specification.
In your case the pairing procedure will be defined for your sesnors in the manufacturer documentation so check there first. Not that you should only have to do this once per device, not every time you want to read the sensor.
Accessing sensor data remotely needs a gateway which I guess is what your Pi will do. The Bluetooth SIG defined a set of RESTFul HTTP APIs for exactly this purpose. See https://www.bluetooth.com/develop-with-bluetooth/white-papers
The SIG also provides a gateway developer resource for Raspberry Pi which you can download including source code which is written in node.js. See https://www.bluetooth.com/develop-with-bluetooth/developer-resources-tools
Good luck
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
i.e. / eg
I have the ‘simple chat’ Arduino app on a RedBearLab Blend-Micro (which is for all intensive purposes the same as a Arduino Uno with a BLE shield) and I only want one single / unique phone to BE ABLE TO connect with it and therefore work with it.
My understanding is that the GAP handles security features during a BLE connection.
Therefore, is there some way to ‘code’ the peripheral device in / below one of the following includes:
spi.h ?
boards.h ?
EEPROM.h ?
RBL_nRF8001.h (or similar) ?
Other?
Didn't quite get an answer from Restricting the BLE peripheral device to connect to only one Master
OR
Am I stuck with EVERYTHING connecting but coding the peripheral in some other way in a GATT profile (I think) to ONLY do something with a predefined unique central/master (how/where to code?).
Many thanks for thoughts in advance
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
Theres the "Advertising Filter Policy" as specified in the Bluetooth Core V4.0 specification. Its a Byte in the Advertising Parameters as specified in Section 7.8.5 LE Set Advertising Parameters Command.
For example the value 0x02 reads Allow Scan Request from Any, Allow Connect Request from White List Only.
Then theres section 7.8.16 LE Add Device To White List Command.
That said, if your device confirms to the Bluetooth 4.0 specification, it should support these HCI commands. However there might be functions that simplify these procedures, wrapping those HCI commands for easier use. Check the Documentation of your device for such methods.
Good Luck!
I was asked to answer this question via email. It's been almost a year since I quit working on BLE. So I only answer this question based on my memories.
Basically #dominik has it right.
If the device is freshly new, it should advertise normally (without setting the whitelist only bit), then any central device could connect and bond. Once it is bonded, you should save this bonded flag and the bonded master's bd_addr to EEPROM. If the next time the master is lost, you will advertise with that white-list-only flag set. If a new central tries to connect, you could verify if its address is the same as your master.
I don't have the BLE spec at hand and I kind of forgot a lot about BLE already. Probably the spec says somewhere that if a central sees a peripheral device is broadcasting with white-list-only flag set, it wouldn't try to connect if it doesn't recognize that peripheral device. This saves both some effort.
But a master could always initiate a connection to your peripheral device regardless the white-list-only flag. So checking if the connecting central device's address is the same as your previously bonded master is the last resort.
[Update]
I used CSR1010 chips. I remembered that the BLE stack actually allows me to insert a list of bd_addr to the white-list data structure maintained by the stack. Then, with the white-list-only flag set, the lower-level stack layer will help you filter devices that are not in that white-list without your knowing.
However, you can always filter bd_addrs from your application code.
Not sure if to posted this on SO.
I'm looking at pretty simple BLE Device. It has a two LEDS (to simplify) that can be switched on or off.
While browsing the GATT profiles, i can't find which profile i should use. Most of them send something back (like a temerature) to the client (upon request).
I need the opposite: switch something on/off of the BLE decive (server). In my case, the client (a iPhone) would send a command to switch on/off LED-1 or LED -2.
What service profile i should use?
Thanks.
I'm using the nRF8001 development kit & nRF Studio for making the services.h
If the LED's are just to be turned on/off there probably isn't any specific profile that they belong to. You probably need to know the handle and write directly to the attribute some value that maps to on or off. Maybe you can figure it out by listing all attribute characteristics. (unfortunately I don't know how to do that specifically on the iPhone)
I noticed that you are using the nRF8001 development kit. So, first thing you need to check is whether the LEDs are connected to IO port of the micro-controller on the kit or directly connected to IO port on BLE chip.
If it connected to micro-controller on the kit then you need to program the kit to handle the received bluetooth data to control led. (It would have a high chance it is in this situation)
If it connected to BLE chip, it means you need to program the ble chip first.
Usually, useful GATT profiles are user specified. It means you need to define the profile yourself. And, I believe some part of the kit or the studio would allow you to do modifications to the profile.
There is only one default GATT profile you should use -- GAP which is to define the defaults like name of the ble device. The others usually are user self-defined profiles.