Jump to content

tripwire

Members
  • Content Count

    193
  • Joined

  • Last visited

  • Days Won

    14

Reputation Activity

  1. Thanks
    tripwire reacted to Rei Vilo in Interfacing BMG250 with TM4C1294XL   
    It looks like the I²C implementation requires a specific period between write and read. 

  2. Like
    tripwire got a reaction from Flirre in CC2650 SensorTag: Low power checklist   
    Here's a list of things to check for if you're getting excessive power consumption on the CC2650 SensorTag - particularly when using TI-RTOS:
    [3.0mA constant] If you're not using the MPU, has it been powered off? By default the Board_MPU_POWER pin is set to output high during startup (TI-RTOS 2.1). [2.9mA when idle] Do you have a power policy set up in the TI-RTOS .cfg file, and is it correctly configured to run when tasks are idle? [0.5mA when SPI inactive] Are the SPI bus pins set to pulldown when the SPI driver is inactive? If they're left floating the serial flash inputs can draw excessive current. [0.27mA constant (?)] Has the TMP007 been placed in shutdown? By default it powers up in 4x oversampling mode with a typical current of 270uA. [0.20mA when alert active (?)] If you're using the TMP007 alert pin function, have you disabled pullup on Board_TMP_RDY? There's an external pullup on the board already... [0.01mA constant] Has the external serial flash been powered down? It takes a typical current of 10uA in standby, which drops to 1uA in power-down. The ones marked (?) are unconfirmed, and are just based on specifications/schematics.
     
    Further to the two TMP007 items on the list: is your TMP007 working at all? If you can't get it to respond to I2C traffic it's possible that it has been damaged. Mine was, and it resulted in additional wasted current of 4mA until I removed the chip. Being a bare die makes it quite vulnerable to damage.
     
    If you're not using SPI then the following code fragment will resolve points 1 and 3:
    static const PIN_Config unusedPinTable[] = { Board_MPU_POWER | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX, // MPU power off Board_SPI0_MOSI | PIN_INPUT_DIS | PIN_PULLDOWN, // disable input, enable pulldown to give a defined level on the bus Board_SPI0_CLK | PIN_INPUT_DIS | PIN_PULLDOWN, // disable input, enable pulldown to give a defined level on the bus PIN_TERMINATE }; // Open unused pins to set correct default state // Define unusedPinHandle and unusedPinState somewhere, either static or global unusedPinHandle = PIN_open(&unusedPinState, unusedPinTable); If you are using SPI you'll need to set up a pin table/handle/state for just the SPI pins, then use PIN_open after SPI_close and PIN_close before the next SPI_open. Alternatively you can just keep the SPI open... but that seems to take an extra ~100uA. I think that's because the uDMA forced to stay powered up.
     
    For point 2, the easiest way to be certain that the power policy is correctly set up is by calling it from a user-defined idle function. That way you can breakpoint the function and be sure that it is called when all tasks are idle.
     
    First you'll need to turn off the option that automatically runs the power policy when tasks are idle:
     

     
    Now add the following code to your project:
    #include <ti/sysbios/family/arm/cc26xx/Power.h> void idleFxn() { Power_standbyPolicy(); // Breakpoint this line to check that the policy is getting called on idle } Finally set up the idle function:
     

     
    Now run the program in the debugger and check that a breakpoint placed in idleFxn is hit during runtime. You can also step in to the Power_standbyPolicy code and see which low power mode it is able to use; sometimes it's prevented from going into full standby due to constraints set by active peripheral drivers.
     
    Removing the user-defined idle function and rechecking the "Invoke power policy when all threads are blocked" should give the same result, but it's harder to confirm that it's working correctly.
     
    The tiny saving from putting the flash into power-down for step 5 is barely worth the effort. You need code to initialise the SPI driver, get the flash into a known state from a potentially unknown one and then put it to sleep. The MCU can be reset without the external flash being power cycled, and JTAG blocks SPI traffic making the code untestable in the debugger. I only did this because I'm using the flash in my project already.
  3. Like
    tripwire reacted to agaelema in DSP and Math lib   
    Hi,
    I'm working in this library with some useful DSP and math functions (ideally focusing on embedded systems). Currently it's in the initial version with few functions, but I hope to add more in the next update.
    I prefered to use some structs to save parameters and use just one function to various instances of filters (very versatile).
    Functions
    - High Pass Filter (Single pole): Float, fixed and fixed extended version (with more bits to fractional part)
    - Low Pass Filter (Single Pole): Float, fixed, fixed extended and fixed fast (with some limitations related to cuttof frequency, but more efficienty.
    - RMS value: calculate RMS value of an array or sample by sample. Currently using square root function of math.h, but in the next update I will add a optimized version.
    I hope this can be useful. Feel free to test, share and contribute with this project.
    Github: https://github.com/agaelema/DSP_and_Math

  4. Like
    tripwire reacted to dubnet in xms432p401r becomes hot   
    By the way, if you are using the XMS version of the MSP432 then you are should have the black board.  I believe that the sensitivity issue has been addressed in the final board release (red board). I know that TI has been pretty strongly recommending moving to the red board since the black board used the pre-production XMS silicon.
  5. Like
    tripwire reacted to energia in Delay() and sleep() have different timing cycles.   
    Thanks @Clavier for the explanation.To add to this. The VLO is only used if the startup code does not detect an external crystal to source ACLK from.
    @tapasxplore Note that the MSP430 max VCC is rated @ 3.6.
    Robert
  6. Like
    tripwire reacted to Clavier in Delay() and sleep() have different timing cycles.   
    The delay() function is part of the official Arduino API. It is implemented with a busy loop, based on the CPU clock.

    The sleep() function is not part of the official Arduino API. It powers down the CPU, and measures time based on the VLO, which doesn't have a accurately specified frequency to begin with and has much higher temperature and voltage coefficients than other clock sources.
  7. Like
    tripwire reacted to dubnet in Reducing power consumption in micro SD card.   
    First off, welcome to the forum.
    A couple of ideas come to mind.  The first is that you might want to consider controlling the power to the SD card with a free I/O line and a transistor, only powering it up when you need to write to it.  The other idea is to store multiple samples in an array (which should survive going into low power mode and back) and write them to the SD card every hour or more. How many samples to store between writes to the SD card would depend on your confidence that you wouldn't lose power or have a reset condition before having a chance to move them to the card.
  8. Like
    tripwire reacted to terjeio in Tiva Reset   
    Sorry for beeing a bit terse again, OR'ing NVIC_APINT_VECTKEY with the bits you want to set is the trick to make it work since  NVIC_APINT_VECTKEY  is the "password" or "guard" bits to allow the other bits to be changed. My point was that some other registers are similarily protected so it is something to be generally aware of.
    Read the documentation carefully is my motto - and do not expect details like this to be found in the context where you might think it should be mentioned.
  9. Like
    tripwire reacted to Rickta59 in SD card not writing any data from microcontroller.   
    Did you read the limitations of the Petit FS?
    ...
    Petit FatFs Limitations:
    Petitfs specifically uses as little flash and stack as possible. This, however, comes at the expense of some functionality. Files are not able be created or increased in size, and only one file can be accessed at a time. 
    ...
    So if you create a zero length file (open a file in a text editor and save it without adding anything to it), it isn't going to do what you want.  If you search the forum or google this is expressed in thousands of posts.
    The comment above comes from this document: http://www.atmel.com/Images/Atmel-42776-Using-the-Petit-FAT-File-System-Module-with-AVR_ApplicationNote_AVR42776.pdf
     
    http://elm-chan.org/fsw/ff/pf/write.html ... 
    Description
    The write function has some restrictions listed below:
    Cannot create file. Only existing file can be written. Cannot expand file size. Cannot update time stamp of the file. Write operation can start/stop on the sector boundary only. Read-only attribute of the file cannot block write operation. File write operation must be done in following sequence.
    pf_lseek(ofs); read/write pointer must be moved to sector bundary prior to initiate the write operation, or it will be rounded-down to the sector boundary at first write operation. pf_write(buff, btw, &bw); Initiate write operation. Write first data to the file. pf_write(buff, btw, &bw); Write next data. Any other file function cannot be used while a write operation is in progress. pf_write(0, 0, &bw); Finalize the current write operation. If read/write pointer is not on the sector boundary, left bytes in the sector will be filled with zero. The read/write pointer in the file system object advances in number of bytes written. After the function succeeded, *bw should be checked to detect end of file. In case of *bw is less than btw, it means the read/write pointer reached end of file during the write operation. Once a write operation is initiated, it must be finalized properly, or the written data can be lost.
     
  10. Like
    tripwire reacted to chicken in Automotive Radar Booster Packs   
    Now here's a set of fancy booster packs! It's a fully integrated automotive radar.
    http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/awr/awr-tools-software.page#tools

    Those rectangles on the right with wiggly traces to the IC are the radar antenna. RF magic!

    The "CAUTION HOT SURFACE" warning label also promises excitement. Too bad they will cost $299 according to the press release.
    Posting in the ARM sub-forum as the radar IC features an R4F ARM core. Though the booster packs probably work with beefier MSP430 LaunchPads too.
    Edit: Here's the mmWave landing page. The AWR also has the non-automotive sibling IWR, including similar booster packs.
    http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/mmwave-overview.page
     
     
  11. Like
    tripwire reacted to NurseBob in What is your Backup Process?   
    @dubnet
    > For your video work where is the bottleneck?
    CPU.  Disk and RAM are not a problem. HD video processing is very, very CPU intensive, and the graphics accelerators and GPUs really don't participate in the rendering process. Overall, I'm not at all unhappy.  I've seen other systems that take easily 8 to 10 times longer to render files similar to mine.  Aside from CPU, the real bottleneck is uploading to youtube, or any other service. A 90 minute video takes about 4-6 hours to upload. On more than one occasion I've had both a render and upload running. No stress for the machine (all twelve threads will be at 40-70% for the render, but the upload really doesn't register on the resources).
    FWIW - the long videos were my recordings of lectures for my nursing students; they were subjected to 3 hour lectures on a weekly basis. Otherwise my goal is less than ten minutes for a topic of interest...
     
  12. Like
    tripwire reacted to chicken in Compiler warnings when using pgm_read_word()   
    For a bit of background:
    Atmel AVR (the chip in the original Arduino) has a Harvard Architecture, which separates program memory (i.e. Flash) from data (i.e. RAM). It uses special assembly commands to read program memory. That's why you need to tell the compiler if you want to store a variable in Flash or access data that's stored in Flash.
    Most other MCUs have a Von Neumann architecture with a unified address space for all types of memory. All access to memory can use the same commands and the compiler decides on where to put things, depending on whether a variable is read-only (Flash) or read-write (RAM).
    To maintain compatibility with code written for AVR, Energia and other non-AVR Arduino implementations replace progmem related commands to basically do nothing without having the compiler complain too much. For the MSP430 see:
    https://github.com/energia/Energia/blob/master/hardware/msp430/cores/msp430/avr/pgmspace.h
    The warning you see is because the replacement for pgm_read_word casts your int to a short.
    #define pgm_read_word(addr) (*(const unsigned short *)(addr)) If you want to get rid of the warning while keeping pgm_read, you could declare your array as an unsigned short instead of int.
     
  13. Like
    tripwire reacted to maelli01 in lpm 4.5 current measurement, fun with low current   
    exactly, and the second diode to make it fool-proof
  14. Like
    tripwire reacted to wulfman in Am i doing something wrong trying to program a 28 tssop 430g2553 with a launchpad   
    Well  looking at the signals with the scope they both look fine. I Removed the cap and it works fine now  go figure.
    Ok. I guess i am losing my mind. I looked at the hardware ref and Doh !  that cap is supposed to be connected to the
    rst line not the test line. It seems that i am going blind. And its supposed to be a .01uf not a .1uf
     
  15. Like
    tripwire reacted to dubnet in msp430g2452 pwm fan controller   
    I forgot to mention that the MCU has an internal temp sensor that  you could potentially use as part of your design.
    Mux resistance is listed at 1K (page 32 of the datasheet). If your source impedance gets too high then you run the risk of more noise. If you find your A/D results bouncing around significantly then you may need to drop from 100K to perhaps 50k or less.  
  16. Like
    tripwire reacted to Rei Vilo in How to view MSP430 assembler code   
    Use Code Composer Studio. It imports Energia projects and provides all the views one can imagine.
  17. Like
    tripwire reacted to greeeg in GPS logger for a local Beagle club   
    This project was put on hold over the holidays. It's always a busy time, plus the club doesn't hold meets over summer.
    But I have just completed another 10 units. More of the same, but thought you guys might enjoy some more photos.





     
    I couldn't get the same batteries as the last batch, which were 650mAh, these have much smaller 220mAh. But this still provides about 4 hours of run time.
    The uBlox GPS modules are a huge improvement. Even without the SAW filter in the RF path and the sub-optimal PCB size compared to the antenna. These find more GPS satellites faster than the G.top modules, plus they also use glonass which doubles the visible satellites.
     
     
  18. Like
    tripwire reacted to maelli01 in lpm 4.5 current measurement, fun with low current   
    The example msp430fr5994x_lpm4-5_02.c is supposed to show how little current is used in this mode.
    In the file it says:
    //   MSP430FR5x9x Demo - Entering and waking up from LPM4.5 via P1.3 interrupt
    //                       with SVS disabled
    //
    //   Description: Download and run the program. When entered LPM4.5, no LEDs
    //                should be on. Use a multimeter to measure current on JP1 and
    //                compare to the datasheet. When a positive voltage is applied
    //                to P1.3 the device should wake up from LPM4.5. This will enable
    //                the LFXT oscillator and blink the LED (on P1.0).
    Even for a high-end multimeter this current is too low to be accurately measured. 
    So I helped myself this way: 
    - power the processor from the supercap
    - a 10k resistor with two antiparallel diodes act as a shunt,  
    - connect the volt meter across the supercap, not across the processor
    0.43mV over a 10k resistor gives 43 Nanoamps. (!)   Yes, the datasheet (page 32) is right, typical value at 25°C is 45nA.  
    A  CR2032 (200mAh) cell would allow the processor to wait for an interrupt  for 530 years. 


  19. Like
    tripwire reacted to chicken in lpm 4.5 current measurement, fun with low current   
    I guess the forward diode is to bypass the 10k resistor when the MCU draws more than 70uA. That's a great trick to remember.
  20. Like
    tripwire reacted to chicken in [POTM] dAISy - A Simple AIS Receiver   
    Hi @wanliban
    Datasheet numbers are hard (impossible?) to hit, especially when the signal comes from a real world target rather than a piece of lab equipment. But you should definitely be able to achieve better than -70 dBm.
    First thing: What does -70 dBm mean in your setup? The level at which you are able to receive any valid messages? Level at which you receive 50% of all messages? 80%? Real world targets or controlled signal from an RF generator?
    You can find my radio_config file and software on GitHub: https://github.com/astuder/dAISy
    Hardware wise, keeping noise out is very important. A bandpass filter in front of the radio helps a lot. Also make sure to minimize the self-inflicted noise by having continuous ground planes in the RF section and keeping the radio away from noisy circuits (like USB). If testing with real-world signals, make sure to use a proper VHF antenna (i.e. not a short rubber duck) and keep the antenna away from other electronics (e.g. monitors or LED and fluorescent light fixtures).
    Also follow Silabs' procedures for RX LNA matching (AN643) and layout recommendations (AN414)
    I hope this helps.
  21. Like
    tripwire reacted to bluehash in 20170311 - Upgrade   
    Hello Everyone,
    Thanks for being patient while the forums were being fixed and upgraded. One Friday morning(March 10th, 2017), the server went down. There was a memory issue, which stalled the SQL server and everything came to halt. 
    it had been fixed by Friday night,  but then went down again due to a mistake I made during the bringup. In the mean time, I also decided to try to upgrade the server(php and peripheral updates) as well as the forum software. I'm going to see how things plan out in the next couple of days.
    Any issues you see with the site, please reply to this thread.
    Thanks!
  22. Like
    tripwire got a reaction from Rei Vilo in [FIXED!] JTAG interferes with SensorTag external flash access   
    Good news! This issue is fixed in the TI Emulators 6.0.228.0 package, which contains the version 2.3.0.1 firmware for XDS110.
     
    TI have added support for 2-wire cJTAG debugging, which only uses the TMS and TCK lines. In the 2.3.0.1 firmware they also stopped the emulator from driving TDO, which was blocking access to the SPI. It looks like 2-wire cJTAG is the default mode now too, so debugging SPI flash code should just work like you'd expect.
  23. Like
    tripwire reacted to bluehash in FourThreeOh wins TI Community Highlight of the Year Award for 2016   
    Thanks @Rei Vilo.
    To all, the award goes to you too. Thanks for being wonderful members.
  24. Like
    tripwire reacted to Rei Vilo in FourThreeOh wins TI Community Highlight of the Year Award for 2016   
    Well deserved, congratulations Gerard!

  25. Like
    tripwire reacted to nickds1 in Easy way to monitor peak stack usage...   
    Hi,
    I needed a way to see how much of my C++ stack was being consumed in my MSP application - the traditional way is to "poison" the stack with a known pattern, and then to see how much of it gets burnt away.
    So I wrote the following - hope folk find it useful:
    The following code allows you to simply do this and to check at any point how much of the pre-allocated stack was consumed during peak usage, i.e. how close your app got to the bottom of the stack, or indeed, whether it over-ran. The TI CCS documentation is completely wrong in the names it gives for the global symbols that define the size and start of the stack - needs to be updated,
    Stick this code (or similar) wherever you want to report on/check stack usage <smallest number of byes left free on the stack since initialisation>/<configured size of the stack>.
    #if defined(STACK_CHECK) std::printf( "Stack: %d/%d\n", stackMinFreeCount(), stackMaxSize() ); #endif and then, in your main code you need to poison the stack as early as possible and then define the reporting routines: // Define STACK_CHECK to include stack usage diagnostics #define STACK_CHECK #if defined(STACK_CHECK) #define STACK_INIT 0xBEEF // Pattern to use to initially poison the stack extern uint16_t _stack; // Start of stack (low address) uint16_t stackMinFreeCount(void); uint16_t stackMaxSize(void); #endif #if defined(__cplusplus) extern "C" { #endif #if defined(__TI_COMPILER_VERSION__) || \ defined(__GNUC__) int _system_pre_init( void ) #elif defined(__IAR_SYSTEMS_ICC__) int __low_level_init( void ) #endif { //... stuff... #if defined(STACK_CHECK) // // Poison the stack, word by word, with a defined pattern // // Note that _system_pre_init is the earliest that we can // do this and that it may not be possible in TI-RTOS // // When we call the __get_SP_register intrinsic (same on IAR & CCS), it will return the address // of the RET address for the caller of this routine. Make sure that we don't trash it!! // register uint16_t *stack = &_stack; // Address of lowest address in .stack section register uint16_t *stack_top = reinterpret_cast<uint16_t *>(__get_SP_register()); do { *stack++ = STACK_INIT; // Poison stack addresses } while (stack < stack_top); // Stop before top of stack to leave RET address #endif return 1; } #if defined(__cplusplus) } #endif #if defined(STACK_CHECK) /** * Check how deep the stack usage has been * * \return \c uint16_t Minimum number of bytes to bottom of stack */ extern uint16_t __STACK_END; // End of data extern uint16_t __STACK_SIZE; // Linker-set size of stack uint16_t stackMinFreeCount(void) { const uint16_t *stack = &_stack; uint16_t freeCount = 0; while (*stack == STACK_INIT && stack++ <= &__STACK_END) { freeCount++; } return freeCount << 1; } /** * Return size of C++ stack * * Set by the linker --stack_size option * * \return \c uint16_t Configued maximum size of the stack in bytes */ uint16_t stackMaxSize(void) { return static_cast<uint16_t>( _symval(&__STACK_SIZE) ); } #endif int main(void) { ... stuff #if defined(STACK_CHECK) std::printf( "Stack: %d/%d\n", stackMinFreeCount(), stackMaxSize() ); #endif ...stuff }  
×
×
  • Create New...