Quantcast
Channel: Microcontrollers
Viewing all 233816 articles
Browse latest View live

Forum Post: MSPM0C1104: Recommended Accelerometer for I2C or SPI connection for low accuracy/cost consumer application

$
0
0
Part Number: MSPM0C1104 Tool/software: Hi, I'm looking for a recommendation for a TI or other manufacturer Accelerometer IC that works over I2C or SPI with the TI MSPM0C1104 and the LP-MSPM0C1104 Evaluation board. The goal is to have Source Code available that is compatible with the low memory footprint of this device ( 1K Bytes SRAM, 16K Bytes FLASH ) to support the accelerometer. It would be great to find a no-solder solution or accelerometer evaluation board that would plug into the TI LP-MSPM0C1104 evaluation board. Looking for works out of the box over the perfect sensor or perfect price. Thanks!

Forum Post: RE: TMS320F28379D: Synchronize ePWM1 with external signal connected at GPIO18

$
0
0
Thanks Allison. Rising edge of the external signal is zero of the EPWM1 up-down carrier. From my code, the rising edge of PWM1 will be at CMPA. As a result, I am seeing delay between rising edge of external signal and rising edge of epwm1. Is there any way I can sync the rising edges of EPWM1A with rising edge external signal with up-down carrier?

Forum Post: RE: LAUNCHXL-F280039C: Why UMCSDK v5.03 ESMO_FAST type 7 motor run mode missing sys_main.c?

$
0
0
[quote userid="525429" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1484300/launchxl-f280039c-why-umcsdk-v5-03-esmo_fast-type-7-motor-run-mode-missing-sys_main-c/5715391#5715391"]The MOTOR1_ESMO algorithm should be able to be enabled without MOTOR1_FAST, and in that case, you should see no runtime calls to the FAST library,[/quote] Hi Jason, The ROM embedded fast estimator included all the control blocks to find the angle, process Clarke and Park transforms to control PWM gate drive, etc.. Why would we use sliding mode observer in closed loop high frequency speed seems a prudent question? Earlier version of UMCSDK required both symbols to run correctly (FAST_ESMO) and the function calls modes were mixed together Notable the Instaspin FOC and Motion users guide (SPRUHJ1H January 2013–Revised June 2019) describes a slow speed open loop sliding observer to get motor spinning below 1Hz. Seemingly the FOC control blocks in GDSVM embedded in ROM can exist in FAST library copied into LSRAM from flash memory. It would help to see a block diagram of ESMO control to clear up any misunderstanding from earlier versions of the example. Below figure is the MCSDK block diagrams partly embedded in ROM. The ROM embed symbol calls can still be asserted in UMCSDK if fast library is not copied into LSRAM. Yet the ROM block shown below is still being used even in fast_full_lib.lib is compiled with the project?

Forum Post: RE: TMS320F28388D: build issue

$
0
0
Thank you for submitting a test case via other methods. I am able to reproduce the same behavior. I filed EXT_EP-12248 to have this investigated. You are welcome to follow it with that link. Thanks and regards, -George

Forum Post: EK-TM4C1294XL: TM4C1294NCPDT

$
0
0
Part Number: EK-TM4C1294XL Tool/software: Hi TI, All, Regarding the EK-TM4C1294XL board, now it works perfectly with the enet_s2e project. Maybe someone could direct me towards the right spot with my following question: Having a transparent serial to ethernet convert is great, but what if I want to filter the messages? Lets say, if I use JSON frames in the payload, as key value pairs, based on the key part, could that be directed or redirected to different UART? Or based on the KEY part, could the message be used to initiate a sensor reading and send the readout as an answer? Thanks for all the suggestions! Gabor

Forum Post: RE: MSPM0G3507: CCSTUDIO chronic 100% cpu

$
0
0
[quote userid="616669" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1479756/mspm0g3507-ccstudio-chronic-100-cpu/5716217#5716217"]I have not installed any extensions that I know of. I DID enabled "check for updates" for clangd so I unchecked that. [/quote] ah ok. That is why you got the message to update from 17.0.3 to 19.1.2. Note we have a 20.1.1 planned some time end of the month (or early next month). It includes and new clangd implementation that addresses several (but not all) known issues. Hope it will help with the issues you are experiencing.

Forum Post: RE: LAUNCHXL-F280049C: TRM SCIFFRX register INT bits 6-7

$
0
0
Hi Jason, [quote userid="525429" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1486509/launchxl-f280049c-trm-sciffrx-register-int-bits-6-7/5716055#5716055"]Second, I'm not certain what you mean when you're referring to a typo related to bits 6 and 7. Bit 7 [RXFFINT] is a read-only flag, while bit 6 [RXFFINTCLR] is a write-only clear bit, which clears RXFFINT.[/quote] Right must have been older version about bit 6 and 7 note. And debug GEL file layout is not same bit locations as depicted in TRM. GEL decode omits reserve bits in decoding the XDS110 emulator returns to the debug simulator. Keep forgetting that at times when deep in the yuck. [quote userid="525429" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1486509/launchxl-f280049c-trm-sciffrx-register-int-bits-6-7/5716055#5716055"]For SCI_clearInterruptStatus(), the excerpt you've posted does not match the behavior defined in Driverlib, which appears correct. I'm afraid I don't understand what you're trying to convey?[/quote] Oddly the driver lib calls cannot clear the RXFIFO overflow condition, not the OE flag. The trouble is those calls cannot clear the FIFO overflow bit first then the interrupt flag to release the FIFO data into the application read buffer without stalling RXISR and locking the RXFIFO. We can only clear the condition manually in debug registers, only in the order just mentioned does the RXFIFO respond to flag bit changes. The application cannot clear the overflow FIFO flag or interrupt even in the TXFIFO calls that continue to function. Have been fighting this overflow issue for very long time not fully understanding what was going wrong. The interrupt flags mentioned above are not the same hex address as one might expect to see during mouse hover over interrupt enable disable code while in debug pause and switching to editor view. Tracing back source interrupt hex address is not so easy to track along with TRM registers view. The way driver lib was written to call an interrupt clear function, the actual PIE flag address is not exposed to CCS editor making troubleshooting very difficult to follow in the TRM registers via offset addresses and target bits to R/W. Why cannot the code snip below clear the RXFIFO overflow condition that manual bit toggle in debug run can easily do like below snip? /* Check SCIFFRX register FIFO has overflowed */ if(SCI_getOverflowStatus(SCIB_BASE) == SCI_FFRX_RXFFOVF) { while(((HWREGH(SCIB_BASE + SCI_O_FFRX) &= SCI_FFRX_RXFFOVF) || (HWREGH(SCIB_BASE + SCI_O_FFRX) &= SCI_FFRX_RXFFINTCLR))) { /* Clear Rx overflow status */ //SCI_clearOverflowStatus(SCIB_BASE); if((HWREGH(SCIB_BASE + SCI_O_FFRX) &= SCI_FFRX_RXFFOVF)) { /* clear SCIFFRX RXFFOVF SCIB */ HWREGH(SCIB_BASE + SCI_O_FFRX) |= SCI_FFRX_RXFFOVRCLR; } else if(HWREGH(SCIB_BASE + SCI_O_FFRX) &= SCI_FFRX_RXFFINTCLR) { /* clear SCIFFRX RXFINT SCIB */ HWREGH(SCIB_BASE + SCI_O_FFRX) |= SCI_FFRX_RXFFINTCLR; } } }

Forum Post: RE: TMS320F28379D: Synchronize ePWM1 with external signal connected at GPIO18

$
0
0
Hello, If you want the rising edge of your EPWM to occur at/around the sync pulse, you need to set your TBPHS value equal to the value of your TBCTR that triggers your rising edge. So if you have a rising edge on CMPA, you need to set TBPHS equal to or before your CMPA value to see that rising edge occur right after a sync. When a sync pulse is seen by the EPWM module, the EPWM's TBPHS value is loaded as the TBCTR value (and then the counter continues on counting from there). This functionality is also explained in our TRM in the EPWM chapter within the Time-Base submodule section: Best Regards, Allison

Forum Post: RE: TMS320F28379D: Synchronize ePWM1 with external signal connected at GPIO18

$
0
0
Understood. This solves my issue. Thanks Allison.

Forum Post: RE: TMS320F2800156-Q1: Attach to a running target

$
0
0
Hi Fernando, On CCS v12.8.1 : Following the steps I provided above, along with modifying the debug configuration to "Load symbols only" and connecting through a debug session (rather than manually connecting to the device i.e. a project-less debug session), I was successfully able to connect to CPU1 without halting the device. I will be looping in the CCS team to see if a similar method is possible on CCS v20 Best, Matt

Forum Post: RE: AM2432: 【EPWM】How to contorol each of PWM FET(High-Side, Low-Side) individually.

$
0
0
Hi Bun, from AM243x TRM I see the following: https://www.ti.com/lit/ug/spruim2h/spruim2h.pdf So, you should be able to control EPWM Channel A and Channel B via AQCTLA and AQCTLB. Also, from same section "12.4.3.4.4.2 Controlling and Monitoring the EPWM Action-Qualifier Submodule" we have: Sofware force actions are useful for asynchronous events, and rea handle via EPWM_AQSFRC and EPWM_AQCSFRC registers. Maybe you can check if the registers are correctly set when using EPWM_aqSwTriggerContAction(), or you can try EPWM_aqSwTriggerOneTimeAction () to see if this can work for you. thank you, Paula

Forum Post: RE: LAUNCHXL-F28P55X: Memory Power On Self Test (MPOST) configuration / Timing

$
0
0
The F28004x device did not have the option of enabling the PLL during MPOST execution, so the 50,000,000 cycles for MPOST would always occur at the INTOSC2 clock rate. As you mentioned, for F28P55x, we have the option of turning on the PLL, so you can just assume 50,000,000 cycles at whichever clock rate you choose, either 150MHz or 75MHz and the associated time with that frequency: 150MHz = 6.67ns *50000000 = ~333ns 75MHz = 13.33ns * 50000000 = ~667ns Best, Matthew

Forum Post: RE: TMS320F280049: How to clear RAM after bootloader ?

$
0
0
Hi Zane, [quote userid="571998" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1488778/tms320f280049-how-to-clear-ram-after-bootloader"]My customer found it maybe some RAM not 0, cause they can't the execute application[/quote] What do you mean by this? After POR, the Boot ROM clear the RAMs but you can use the RAM INIT feature (please refer to the Memory Controller section in TRM ) to clear the RAM content. Best, Matt

Forum Post: RE: TMS320F2800156-Q1: Attach to a running target

$
0
0
[quote userid="621965" url="~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1487727/tms320f2800156-q1-attach-to-a-running-target/5713117#5713117"] For OnTargetConnect() in the gel file (ti\ccs2010\ccs\ccs_base\emulation\gel\f2800156.gel): Are you commenting out the GEL_Reset() call? Are you commenting out the RAM initialization lines? In CCS > Project Properties > Debug > Connection Options: Do you have "Reset the target on a connect" unchecked? [/quote] These are all good steps. I can confirm that I can connect non-intrusively to my F2800157 LaunchPad with both CCS 12.8.1 and CCS 20.1.0 with the above steps (I actually am not using a startup GEL script at all).

Forum Post: RE: SM320F28335-EP: V62/09624-01YE - 176 pin QFP, Corner Staking

$
0
0
Joe, I am not aware of a need for corner staking for this package, at least in my interactions with other customers this has not come up. Here is an application note on our power pad packages, if you need further information I'll need to get some folks from our package team on this thread. Let me know. https://www.ti.com/lit/an/slma002h/slma002h.pdf Best, Matthew

Forum Post: RE: MSPM0C1104: SWD Multi-Drop Support

$
0
0
Hi Kristofer, I think this is possible if you use the C-GANG. Here's a link to it: https://www.ti.com/tool/C-GANG Best Regards, Diego Abad

Forum Post: RE: SM320F28335-HT: Operating Temperature

$
0
0
Arif, The die used for this part number, regardless of the package is the same; but given that the GB is a ceramic package(with much lower thermal conductivity) vs a plastic package in the PTP is what I am unsure about. Running the device slower, can help address the power consumption/thermal equation part of things, i.e. making sure the junction temp of the die inside the PTP is ~ what the die inside the GB would be under similar circumstances. I just don't know if the plastic compounds used for the PTP will hold up above the 150C mentioned in the DS, since we capped this at 150C I would suspect that the package itself, vs the thermals of the die, is what is going to fail first. I would not recommend running the PTP outside the DS limits, nor do we have any data outside those limits on how the device or package will behave. Best, Matthew

Forum Post: RE: LAUNCHXL-F28P65X: Self-test of timer

$
0
0
1. We don't have one in the SDL currently, but it should be fairly straightforward for the customer to implement. The STL_OSC_CT test as you've pointed out is very similar, so you could use it as reference (start the timer, delay for a known amount of time, stop the timer). Instead of just checking the count like we do in STL_OSC_CT, you could instead enable interrupts and count that the number of Timer interrupts that executed during the delay is as expected. This makes sure that the timer is running at the expected rate and capable of generating interrupts. 2. No, Timer 2 should be running off of an independent clock source from the SYSCLK (and therefore Timers 0 and 1). For example, if SYSCLK is using an external clock source, the STL_OSC_CT test should have CPU Timer 2 run off of one of the INTOSC, so that it is independent. Also the purpose of the timer test is to test the timer itself, not necessarily the clock source (e.g. the clock source could be working fine, but there could be a fault in the Timer 0 counter). Whitney

Forum Post: RE: MSPM0L1106: Question on GPIO settings :

$
0
0
Hi Alan, 3. Let me consult about this 4. The configuration you are doing seems good to me (except for the resetGPIO.) However, the if else define statement is weird to me since it seems it runs all codes at the same time (makes it input, then output low, and then output high.) I will try just configuring one at a time, and see what addition of your code makes it break. Something like this: #if 0 DL_GPIO_initDigitalInput(GPIO_GRP_0_PIN_0_IOMUX); DL_GPIO_initDigitalInputFeatures( GPIO_GRP_0_PIN_0_IOMUX, DL_GPIO_INVERSION_DISABLE, DL_GPIO_RESISTOR_NONE, DL_GPIO_HYSTERESIS_DISABLE, DL_GPIO_WAKEUP_DISABLE ); DL_GPIO_initDigitalInput(GPIO_GRP_0_PIN_1_IOMUX); DL_GPIO_initDigitalInputFeatures( GPIO_GRP_0_PIN_1_IOMUX, DL_GPIO_INVERSION_DISABLE, DL_GPIO_RESISTOR_PULL_UP, DL_GPIO_HYSTERESIS_DISABLE, DL_GPIO_WAKEUP_DISABLE ); #endif #if 1 DL_GPIO_initDigitalOutput(GPIO_GRP_0_PIN_0_IOMUX); DL_GPIO_initDigitalOutput(GPIO_GRP_0_PIN_1_IOMUX); DL_GPIO_enableOutput(GPIOA, DL_GPIO_PIN_2); DL_GPIO_enableOutput(GPIOA, DL_GPIO_PIN_3); DL_GPIO_clearPins(GPIOA, DL_GPIO_PIN_2); DL_GPIO_clearPins(GPIOA, DL_GPIO_PIN_3); #endif #if 2 DL_GPIO_setPins(GPIOA, DL_GPIO_PIN_2); DL_GPIO_setPins(GPIOA, DL_GPIO_PIN_3); #endif Best Regards, Diego Abad

Forum Post: RE: TMS320F28P550SJ: profiling and time analysis with JTAG

$
0
0
Hi Hongyu, For the C2000 family of devices, the main differentiator of the XDS560v2 over the XDS110 is the considerable speed enhancement (along with being a higher cost debugger). C28x devices do not support the core and system trace feature on the TMDSEMU560V2STM-U . You can refer to the Debug Probe Performance Comparison for an objective analysis of the executable/binary throughput, console I/O, and single step interactive tests on C2000 devices with various JTAG debuggers: https://software-dl.ti.com/ccs/esd/documents/application_notes/appnote-debug_probe_performance_results.html#f28379d For debugging capabilities on F28P55x, I recommend you refer to the ERAD chapter in the TRM . The ERAD module enhances the debug and system analysis capabilities of the device and is accessible both by the debugger and the application software, which significantly increases the debug capabilities of many real-time systems. We have examples in the C2000Ware driverlib folder (driverlib\f28p55x\examples\erad\debugger_owned_examples) including function and interrupt profiling. Best, Matt
Viewing all 233816 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>