Part Number:TIDA-01417
Hello,
we plan to do a new design with UCC28740. Do you've got some measures about Conductive EMI 230VAC according EN55015Q and EN55022A.
We found no measures in all documents. Did it meet the specs? If you don't have further information can we lend TIDA-01417 reference design?
Best regards,
Toby
Part Number:SIMPLELINK-MSP432-SDK
Tool/software:TI-RTOS
I am trying to post a semaphore from my UART HWI and I"m getting an exception:
My setup is as follow:
ti.sysbios.knl.Task: line 424: E_spOutOfBounds: Task 0x200099f0 stack error, SP = 0x20008ac4. xdc.runtime.Error.raise: terminating execution
I believe this is because the the HWI's are running as zero-latency interrupts.
It seems like these interrupts also prevent me from passing a param into the HWI.
Is there any way I can disable the zero-latency interrupt for these, so I can make the OS Calls?
Cfg File Example:
/* ================ Hwi configuration ================ */
var halHwi = xdc.useModule('ti.sysbios.hal.Hwi');
var m3Hwi = xdc.useModule('ti.sysbios.family.arm.m3.Hwi');
/*
* Checks for Hwi (system) stack overruns while in the Idle loop.
*
* Pick one:
* - true (default)
* Checks the top word for system stack overflows during the idle loop and
* raises an Error if one is detected.
* - false
* Disabling the runtime check improves runtime performance and yields a
* reduced flash footprint.
*/
halHwi.checkStackFlag = true;
//halHwi.checkStackFlag = false;
/*
* The following options alter the system's behavior when a hardware exception
* is detected.
*
* Pick one:
* - Hwi.enableException = true
* This option causes the default m3Hwi.excHandlerFunc function to fully
* decode an exception and dump the registers to the system console.
* This option raises errors in the Error module and displays the
* exception in ROV.
* - Hwi.enableException = false
* This option reduces code footprint by not decoding or printing the
* exception to the system console.
* It however still raises errors in the Error module and displays the
* exception in ROV.
* - Hwi.excHandlerFunc = null
* This is the most aggressive option for code footprint savings; but it
* can difficult to debug exceptions. It reduces flash footprint by
* plugging in a default while(1) trap when exception occur. This option
* does not raise an error with the Error module.
*/
m3Hwi.enableException = true;
//m3Hwi.enableException = false;
//m3Hwi.excHandlerFunc = null;
/*
* Enable hardware exception generation when dividing by zero.
*
* Pick one:
* - 0 (default)
* Disables hardware exceptions when dividing by zero
* - 1
* Enables hardware exceptions when dividing by zero
*/
m3Hwi.nvicCCR.DIV_0_TRP = 0;
//m3Hwi.nvicCCR.DIV_0_TRP = 1;
/*
* Enable hardware exception generation for invalid data alignment.
*
* Pick one:
* - 0 (default)
* Disables hardware exceptions for data alignment
* - 1
* Enables hardware exceptions for data alignment
*/
m3Hwi.nvicCCR.UNALIGN_TRP = 0;
//m3Hwi.nvicCCR.UNALIGN_TRP = 1;
/***** Some Other Stuff ****/
halHwi.dispatcherAutoNestingSupport = false;
var halHwi0Params = new halHwi.Params();
halHwi0Params.instance.name = "hHwiEusciA2";
halHwi0Params.arg = 2;
halHwi0Params.enableInt = false;
halHwi0Params.priority = 3;
Program.global.hHwiEusciA2 = halHwi.create(34, "&Msp432UartIsrA2", halHwi0Params);
var halHwi1Params = new halHwi.Params();
halHwi1Params.instance.name = "hHwiEusciA0";
halHwi1Params.priority = 3;
halHwi1Params.enableInt = false;
Program.global.hHwiEusciA0 = halHwi.create(32, "&Msp432UartIsrA0", halHwi1Params);
Part Number:TPS40170
I am looking for information on modifying or developing a high precision, low noise, variable, switched mode constant current source. We have made several using TPS40170 or LM5176 but have never achieved excellent performance. Most of the designs provide 4-8% ripple. We will consider other controllers.
Specifically, our requirements are:
Vin range: 28V +/- 5%
Io: 0-15A linearly controllable by voltage
Io ripple: <0.5% of Io
Vo compliance: 10 - 22V
Efficiency: > 98%
Regards
Ken
Part Number:TPL0401A-10
Hello,
Can you get confirmation that this part can work in the following application?
Directly placed at FB pin of an LDO.
Thank you,
Part Number:TPS55332-Q1
Hello!
I am simply trying to mirror the provided schematic in the datasheet for TPS55332, but the provided pcb layout (page 25) has signficantly more components than the schematic a few pages prior. Is there a schematic available for the provided PCB layout?
Thanks,
Part Number:TM4C123GH6PM
Hi,
I am a bit confused with the JTAG interface's pull up/down resistors because it seems to be different depending on who you ask.
In TI's document: "Using TM4C12x Devices over JTAG interface" (page 10) the ARM 10-Pin (Cortex Debug) Header is connected using this configuration:
| TMS | Pull-Up (10K) |
| TCK | Pull-Up (10K) |
| TDO | Pull-Down (10K) |
| TDI | None |
| RST | None |
(In this document, and only in the 10-Pin header case, there are also 33Ohms series resistors for all the lines but the RST)
But in the Tiva TM4C123G LaunchPad schematics from TI, they don't use the TDO pull-up, neither the 33Ohms resistors... so what is it?
And if you search a little more you find other configurations:
In this NXP site they use a pull-down resistor for TCK and pull-up resistors for TDI and TDO, totally different from TI..
Xilinx uses only pull-ups in all the lines except the TDO that is left alone
I am using a TM4C123GH6PM microcontroller from TI so it seems safer to follow they design guidelines but it is surprising to find all this different configurations for something that should be an standard.
Even focusing in what TI suggest, what policy should I use? the one from the design guide or the one in the Tiva Launchpad schematics???
Thanks!
Part Number:TM4C129XNCZAD
Tool/software:TI-RTOS
I am seeking a general approach to figuring out why a TI-RTOS project reaches abort() seen in the screen shot below. I have a few tasks and I am not sure what triggers my error.
What are the six values printed to the console? I assume FSR was "fault status register", but the memory browser tells me FAULT_STAT is set to 0x00000400 in this case (Imprecise data bus error). The BFARV bit isn't set, so I can't see the address that cause the fault in the FAULTADDR register
The exception stack frame described in Diagnosing Software Faults in Stellaris® Microcontrollers AN01286 indicates the PC value was 0x20000548 according to the screenshot below. This SRAM location does not appear to have opcodes. The other values don't seem to ever match the core registers. The LR value also indicates the PC was operating from SRAM. I do not know what code is in SRAM or how to debug it.
The guide says "If your fault handler function has any code besides a simple infinity loop, then it may use some stack space. You must adjust the value of the stack pointer by this amount in order to find the start of the exception stack frame." Is abort() taking the place of FaultISR()? The _pem4f.c file seems to place ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I at the fault vectors. What is the size of the fault handler function? Am I looking at the actual exception stack frame?
I am not sure how to fine the fault in my code based on this output.
Part Number:SN74LVC245A
Would like to connect the interface device having 5V with Raspberry pi SPI (3)
is that possible to use level shifter (SN74LVC245A) or should we use TxB0104 bi-directional level Shitfer ?
Interface device breakout board with 5V communicate with RPI over SPI 4 Wires
SCK
MISO
MOSI
SS to
Level Shifter SN74LVC245A is also meant for SPI communication.
Part Number:SN54ACT573
Team,
My customer has the following question.
We use the 54ACT573 (procured to SMD-87664) in one of our designs. During board level test the Latch Enable Input was left floating (no connection). Can you confirm that leaving that pin floating while powered up is non-stressful to the part?
Thanks,
Aaron
Part Number:MSP432P401R
I need to build an OTA update mechanism for a project we are working on, and I am not quite sure where to begin. I know I need to develop a bootloader (Is this different from the BSL?), but I am not quite sure how to do that. Is there any example code or things I can reference?
A little bit about my project: We are using CCS v7, with an MSP-FET to program the MSP432P401R. Our bin file is about 50kb. The WiFi device that we use is an ESP8266, with a custom instruction set.
I have looked at this article: http://dev.ti.com/tirex/content/simplelink_sdk_wifi_plugin_1_50_00_38/docs/msp432_ota_wifi_updates/ota/msp432_ota_wifi_updates.html However, I could not find any files to download, and I got completely lost when they started talking about UniFlash.
Please let me know what I need to reference in order to get started on this. Thanks!
Part Number:BQ40Z60
Hi,
seems with all the possible charge programming possibilities there is one missing...
Here is what i would like to do:
0C to 10C, Charge Voltage = 4.20V
10C to 45C, Charge Voltage = 4.20V
45C to 50C, Charge Voltage = 4.15V
50C to 60C, Charge Voltage = 4.1V
I'd like to make Standard Low Charging Voltage and Standard Hi Charging Voltage different but there seems to be only one voltage setting for both(??)
SLUUA04D, Figure 4-4 shows 5 Constant Current Mode Matrix columns:
- LT, Low Temp
- STL, Standard Temp Low
- RT, Recommended Temp
- STH, Standard Temp Hi
- HT, High Temp
and
bqStudio/ DataMemory/ Advanced Charge Algorithm/ shows 4:
- Low Temp Charging
- Standard Temp Charging (?Lo& Hi?)
- High Temp Charging
- Rec Temp Charging
Our Panasonic NCR18650B battery can use separate Standard Temp Charging voltages for the Lo = 4.2V & Hi =4.15V
any ideas how to over come this issue other than making the Lo = 4.15V like Hi = 4.15V for a narrow temperature range (10C to 12C)?
I'm under the impression T1 -> T2 -> T5 -> T6 -> T3 -> T4-> need to be increasing (can T2 = T5?? = 10C)
am i missing something?
thanks,
Tom
Part Number:BEAGLEBK
Tool/software: Linux
Hello,
I'm trying to put my BeagleBone Black into 24-bit LCD mode, but it isn't working. Instead, I get 16-bit mode. I'm driving an all Red test pattern and get all Blue on screen due to the Sitara Errata notes in 3.1.1. If the Sitara would go into 24-bit mode, I should have the correct color. I have also probed the LCD lines and found that only LCD_Data0 - LCD_Data15 are active.
I am running Kernel 4.9.79 from the Processor SDK.
Here is my Device Tree, shouldn't this put it into 24-bit mode?
/dts-v1/;
#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
#include <dt-bindings/display/tda998x.h>
/ {
model = "TI AM335x BeagleBone Black";
compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
};
&ldo3_reg {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
&mmc1 {
vmmc-supply = <&vmmcsd_fixed>;
};
&mmc2 {
vmmc-supply = <&vmmcsd_fixed>;
pinctrl-names = "default";
pinctrl-0 = <&emmc_pins>;
bus-width = <8>;
status = "okay";
};
&cpu0_opp_table {
/*
* All PG 2.0 silicon may not support 1GHz but some of the early
* BeagleBone Blacks have PG 2.0 silicon which is guaranteed
* to support 1GHz OPP so enable it for PG 2.0 on this board.
*/
oppnitro@1000000000 {
opp-supported-hw = <0x06 0x0100>;
};
};
&am33xx_pinmux {
lcd_pins: lcd_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x8a0, PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0 */
AM33XX_IOPAD(0x8a4, PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1 */
AM33XX_IOPAD(0x8a8, PIN_OUTPUT | MUX_MODE0) /* lcd_data2.lcd_data2 */
AM33XX_IOPAD(0x8ac, PIN_OUTPUT | MUX_MODE0) /* lcd_data3.lcd_data3 */
AM33XX_IOPAD(0x8b0, PIN_OUTPUT | MUX_MODE0) /* lcd_data4.lcd_data4 */
AM33XX_IOPAD(0x8b4, PIN_OUTPUT | MUX_MODE0) /* lcd_data5.lcd_data5 */
AM33XX_IOPAD(0x8b8, PIN_OUTPUT | MUX_MODE0) /* lcd_data6.lcd_data6 */
AM33XX_IOPAD(0x8bc, PIN_OUTPUT | MUX_MODE0) /* lcd_data7.lcd_data7 */
AM33XX_IOPAD(0x8c0, PIN_OUTPUT | MUX_MODE0) /* lcd_data8.lcd_data8 */
AM33XX_IOPAD(0x8c4, PIN_OUTPUT | MUX_MODE0) /* lcd_data9.lcd_data9 */
AM33XX_IOPAD(0x8c8, PIN_OUTPUT | MUX_MODE0) /* lcd_data10.lcd_data10 */
AM33XX_IOPAD(0x8cc, PIN_OUTPUT | MUX_MODE0) /* lcd_data11.lcd_data11 */
AM33XX_IOPAD(0x8d0, PIN_OUTPUT | MUX_MODE0) /* lcd_data12.lcd_data12 */
AM33XX_IOPAD(0x8d4, PIN_OUTPUT | MUX_MODE0) /* lcd_data13.lcd_data13 */
AM33XX_IOPAD(0x8d8, PIN_OUTPUT | MUX_MODE0) /* lcd_data14.lcd_data14 */
AM33XX_IOPAD(0x8dc, PIN_OUTPUT | MUX_MODE0) /* lcd_data15.lcd_data15 */
/* elinux.org/24bit_LCD_for_BBB */
0x3c 0x09 /* lcd_data16.lcd_data16, OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
0x38 0x09 /* lcd_data17.lcd_data17, OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
0x34 0x09 /* lcd_data18.lcd_data18, OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
0x30 0x09 /* lcd_data19.lcd_data19, OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
0x2c 0x09 /* lcd_data20.lcd_data20, OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
0x28 0x09 /* lcd_data21.lcd_data21, OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
0x24 0x09 /* lcd_data22.lcd_data22, OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
0x20 0x09 /* lcd_data23.lcd_data23, OMAP_MUX_MODE1 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
AM33XX_IOPAD(0x8e0, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_vsync.lcd_vsync */
AM33XX_IOPAD(0x8e4, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_hsync.lcd_hsync */
AM33XX_IOPAD(0x8e8, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_pclk.lcd_pclk */
AM33XX_IOPAD(0x8ec, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_ac_bias_en.lcd_ac_bias_en */
AM33XX_IOPAD(0x878, PIN_OUTPUT_PULLDOWN | MUX_MODE7)
>;
};
backlight_pin: backlight_pin {
pinctrl-single,pins = <
AM33XX_IOPAD(0x848, PIN_OUTPUT_PULLUP | MUX_MODE6)
>;
};
bb_spi0_pins: pinmux_bb_spi0_pins {
pinctrl-single,pins = <
0x150 0x30 /* spi0_sclk.spi0_sclk, INPUT_PULLUP | MODE0 */
0x154 0x30 /* spi0_d0.spi0_d0, INPUT_PULLUP | MODE0 */
0x158 0x10 /* spi0_d1.spi0_d1, OUTPUT_PULLUP | MODE0 */
0x15c 0x10 /* spi0_cs0.spi0_cs0, OUTPUT_PULLUP | MODE0 */
>;
};
};
&spi0 {
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&bb_spi0_pins>;
channel@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "spidev";
reg = <0>;
spi-max-frequency = <16000000>;
};
};
&lcdc {
status = "okay";
};
&epwmss1 {
status = "okay";
};
&ehrpwm1 {
pinctrl-names = "default";
pinctrl-0 = <&backlight_pin>;
status = "okay";
};
&rtc {
system-power-controller;
};
&sgx {
status = "okay";
};
/ {
lcd0: display {
status = "okay";
compatible = "ti,tilcdc,panel";
label = "lcd";
pinctrl-names = "default";
pinctrl-0 = <&lcd_pins>;
panel-info {
ac-bias = <255>;
ac-bias-intrpt = <0>;
dma-burst-sz = <16>;
bpp = <24>;
fdd = <0x80>;
sync-edge = <0>;
sync-ctrl = <1>;
raster-order = <0>;
fifo-th = <0>;
};
display-timings {
native-mode = <&timing0>;
timing0: 240x320 {
clock-frequency = <7200000>;
hactive = <240>;
vactive = <320>;
hfront-porch = <38>;
hback-porch = <10>;
hsync-len = <10>;
vback-porch = <4>;
vfront-porch = <8>;
vsync-len = <4>;
hsync-active = <0>; // Low active
vsync-active = <0>; // Low active
de-active = <1>; // The data DB17-0 is written when ENABLE = “1”. Disable data write operation when ENABLE = “0”.
pixelclk-active = <1>; // The data is input on the positive edge of DOTCLK
};
};
};
fb {
compatible = "ti,am33xx-tilcdc";
reg = <0x4830e000 0x1000>;
interrupt-parent = <&intc>;
interrupts = <36>;
ti,hwmods = "lcdc";
};
backlight {
status = "okay";
compatible = "pwm-backlight";
pwms = <&ehrpwm1 0 500000 0>;
brightness-levels = <
0 1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17 18 19
20 21 22 23 24 25 26 27 28 29
30 31 32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47 48 49
50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69
70 71 72 73 74 75 76 77 78 79
80 81 82 83 84 85 86 87 88 89
90 91 92 93 94 95 96 97 98 99
100
>;
default-brightness-level = <100>;
};
};
Part Number:TM4C129ENCPDT
The lwIP 1.4.1 support in Tivaware is quite old. Many developers on the internet recommend starting new projects on lwIP 2.0.x, especially when combining multiple open-source embedded libraries.
Has anyone successfully updated the TM4C port of lwIP from 1.4.1 to 2.0.x?
It looks like the interrupt versus main() master loop calls need to move around. I've been working with 2.0.3 and looking at NonGNU.org and ARMmbed/lwip, but there are some interesting discrepancies.
Any help?
Part Number:EK-TM4C1294XL
Hi, so I have to use multiple UART ports for my project - one of which I will wait for a key word and respond with a corresponding string. I am having two main problems:
My receive function only will receive only 6 characters without messing up - I can work around this and make all keywords only 6 characters max but I think there is a bigger underlying issue which I need to watch out for. I am kind of stuck and I am not sure where my errors are any advice, help or pointing in some direction would be very appreciated
void EnableUART0(void)
{
//
// Enable GPIO and UART 0
//
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
//
// Configure UART Pins for UART MODE
//
GPIOPinConfigure(GPIO_PA0_U0RX);
GPIOPinConfigure(GPIO_PA1_U0TX);
GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
UARTClockSourceSet(UART0_BASE, UART_CLOCK_SYSTEM);
UARTConfigSetExpClk(UART0_BASE, g_ui32SysClock, 115200, UART_CONFIG_WLEN_8 | UART_CONFIG_PAR_NONE | UART_CONFIG_STOP_ONE);
IntRegister(INT_UART0, UART0Get);
IntEnable(INT_UART0);
UARTIntEnable(UART0_BASE, UART_INT_RX | UART_INT_RT);
}
void UART0print(const char* text)
{
const char* p;
// Iterate over each character of `text`,
// until we reach the NUL terminator
for (p = text; *p != '\0'; p++)
{
// Pass each character to some function
UARTCharPut(UART0_BASE, *p);
}
}
void UART0Get(void)
{
int i = 0;
// if (UARTCharsAvail(UART0_BASE) == true)
while(UARTCharsAvail(UART0_BASE))
{
Incoming1[i] = UARTCharGetNonBlocking(UART0_BASE);
++i;
// int i;
// for(i=0;i<21;i++) // maybe change 21 to something more realistic in the future >>>
// {
// Incoming1[i] = UARTCharGetNonBlocking(UART0_BASE);
// }
}
}The issue I am referring to is with regards to the UART0Get function - which will only work for 6 characters max without an issue, slightly beyond 6 characters for example 7, it will eliminate the first character and print out the last 6 for example if I send "1234567" it will only store "234567". If I send something much larger than 6 then it acts very randomly, I do not understand what is happening.
In my main function I am trying to get it to recognize that I send the word "Temp" and it should reply back with an arbitrary string value I am using for now during testing:
int
main(void)
{
g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
SYSCTL_OSC_MAIN |
SYSCTL_USE_PLL |
SYSCTL_CFG_VCO_480), 120000000);
FPUEnable();
//FPURoundingModeSet(FPU_ROUND_POS_INF);
IntMasterEnable(); // Enable the processor to respond to interrupts.
//configureUARTTesting();
EnableUART0();
while(1)
{
UART0print(Incoming1);
if (strcmp(Incoming1,"Temp") == 0)
{
UART0print(TempValue);
// UART0print(Incoming1);
}
// UART0print(Test);
// UART0print(Line);
// UART0print(Incoming1);
// UART0print(Line);
// UART0print(Inductance);
// UART0print(Line);
// UART0print(Frequency);
// UART0print(Line);
}
}TempValue is just a string variable I had saved earlier and looks like this
char TempValue[] = "50 Deg";
Incoming1 is just a char array meant to store the incoming chars sent in over UART and is defined as follows
char Incoming1[15];
In the beginning I had tried to keep Incoming1 an array without a set number of spaces but that caused even more problems, which seemed to go away when I typed a value into Incoming1 such as 15 in this case.
Part Number:AM3358
Tool/software: Code Composer Studio
We have been debugging a custom prototype board which uses Octavo's OSD3358-SM, the same chip inside Beaglebone's PocketBeagle and contains the AM335x embedded. While trying to access the chip using the JTAG interface with Code Composer Studio, I set up the target configuration to support AM3358 and then attempted to test the connection. The integrity tests fail every single time, the results of the test are shown below:
[Start: Texas Instruments XDS100v2 USB Debug Probe_0] Execute the command: %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity [Result] -----[Print the board config pathname(s)]------------------------------------ /home/avionica/.ti/ti/0/1/BrdDat/testBoard.dat -----[Print the reset-command software log-file]----------------------------- This utility has selected a 100- or 510-class product. This utility will load the adapter 'libjioserdesusb.so'. The library build date was 'Feb 8 2018'. The library build time was '18:25:14'. The library package version is '7.0.188.0'. The library component version is '35.35.0.0'. The controller does not use a programmable FPGA. The controller has a version number of '4' (0x00000004). The controller has an insertion length of '0' (0x00000000). This utility will attempt to reset the controller. This utility has successfully reset the controller. -----[Print the reset-command hardware log-file]----------------------------- The scan-path will be reset by toggling the JTAG TRST signal. The controller is the FTDI FT2232 with USB interface. The link from controller to target is direct (without cable). The software is configured for FTDI FT2232 features. The controller cannot monitor the value on the EMU[0] pin. The controller cannot monitor the value on the EMU[1] pin. The controller cannot control the timing on output pins. The controller cannot control the timing on input pins. The scan-path link-delay has been set to exactly '0' (0x0000). -----[The log-file for the JTAG TCLK output generated from the PLL]---------- There is no hardware for programming the JTAG TCLK frequency. -----[Measure the source and frequency of the final JTAG TCLKR input]-------- There is no hardware for measuring the JTAG TCLK frequency. -----[Perform the standard path-length test on the JTAG IR and DR]----------- This path-length test uses blocks of 64 32-bit words. The test for the JTAG IR instruction path-length succeeded. The JTAG IR instruction path-length is 6 bits. The test for the JTAG DR bypass path-length succeeded. The JTAG DR bypass path-length is 1 bits. -----[Perform the Integrity scan-test on the JTAG IR]------------------------ This test will use blocks of 64 32-bit words. This test will be applied just once. Do a test using 0xFFFFFFFF. Scan tests: 1, skipped: 0, failed: 0 Do a test using 0x00000000. Scan tests: 2, skipped: 0, failed: 0 Do a test using 0xFE03E0E2. Test 3 Word 0: scanned out 0xFE03E0E2 and scanned in 0xFE01E062. Test 3 Word 1: scanned out 0xFE03E0E2 and scanned in 0xFE01E062. Test 3 Word 2: scanned out 0xFE03E0E2 and scanned in 0xFE01E0FC. Test 3 Word 3: scanned out 0xFE03E0E2 and scanned in 0xFE01E0FC. Test 3 Word 4: scanned out 0xFE03E0E2 and scanned in 0xFE01E0FC. Test 3 Word 5: scanned out 0xFE03E0E2 and scanned in 0xFE01E0FC. Test 3 Word 6: scanned out 0xFE03E0E2 and scanned in 0xFE01E0FC. Test 3 Word 7: scanned out 0xFE03E0E2 and scanned in 0xFE01E0FC. The details of the first 8 errors have been provided. The utility will now report only the count of failed tests. Scan tests: 3, skipped: 0, failed: 1 Do a test using 0x01FC1F1D. Scan tests: 4, skipped: 0, failed: 2 Do a test using 0x5533CCAA. Scan tests: 5, skipped: 0, failed: 3 Do a test using 0xAACC3355. Scan tests: 6, skipped: 0, failed: 4 Some of the values were corrupted - 65.1 percent. The JTAG IR Integrity scan-test has failed. -----[Perform the Integrity scan-test on the JTAG DR]------------------------ This test will use blocks of 64 32-bit words. This test will be applied just once. Do a test using 0xFFFFFFFF. Scan tests: 1, skipped: 0, failed: 0 Do a test using 0x00000000. Scan tests: 2, skipped: 0, failed: 0 Do a test using 0xFE03E0E2. Test 3 Word 32: scanned out 0xFE03E0E2 and scanned in 0xFE03E0E0. Test 3 Word 37: scanned out 0xFE03E0E2 and scanned in 0xFE03E0E0. Scan tests: 3, skipped: 0, failed: 1 Do a test using 0x01FC1F1D. Test 4 Word 16: scanned out 0x01FC1F1D and scanned in 0x01FC1F1C. Test 4 Word 24: scanned out 0x01FC1F1D and scanned in 0x01FC1F1C. Test 4 Word 29: scanned out 0x01FC1F1D and scanned in 0x01FC1F1C. Scan tests: 4, skipped: 0, failed: 2 Do a test using 0x5533CCAA. Test 5 Word 8: scanned out 0x5533CCAA and scanned in 0x5533CCA2. Test 5 Word 10: scanned out 0x5533CCAA and scanned in 0x1133CCAA. Test 5 Word 11: scanned out 0x5533CCAA and scanned in 0x1533CCAA. The details of the first 8 errors have been provided. The utility will now report only the count of failed tests. Scan tests: 5, skipped: 0, failed: 3 Do a test using 0xAACC3355. Scan tests: 6, skipped: 0, failed: 4 Some of the values were corrupted - 7.3 percent. The JTAG DR Integrity scan-test has failed. [End: Texas Instruments XDS100v2 USB Debug Probe_0]
What could be causing the JTAG failures on the chip?
Part Number:CSD95490Q5MC
Hello,
I'm trying to realize a 6 phase 240A power converter using the TPS53681 and CSD95490Q5MC. The load is an Altera/Intel FPGA and they have provided a calculator for the Power Distribution Network (PDN). In order to calculate the source impedance of the VRM, we need to provide an ideal model with equivalent resistance and inductance:
We have almost all the information we need, with the notable exception of the power stages. Would you be able to help us obtain these figures? I don't see resistance or inductance information posted in the datasheet.
Our end goal is to represent the power supply as follows:
Any help you can provide would be greatly appreciated.
Don
We have a customer asking about the 78SR105TC (Obsolete). They are looking for the package type for the "T".
I realize this is a SIP module, however, the customer needs to know whether the T reflects the horizontal or vertical version of this device.
Could someone please advise?
Thanks,
Part Number:LMR23630-Q1
Hi,
I'm looking into bread boarding the LMR23630, I understand it's higher frequency and not the greatest application for a breadboard. I'm using the reference design, and have made my own makeshift groundplane/headsink for the ground pad. My schematic is based off the reference design for 5V/3A which is in the datasheet. Here are a few dumb questions:
1. The orientation of the chip.
In the datasheet there's the typical circle signifying pin one, but from pictures of the chips there's almost no markings besides the text and the gold bar on one side, would it be safe to say that the orientation can be decided from the text on the chip?
2. Testing stages
Would I be able to hookup VIN, EN_SYNC, and VCC plus ground pins (PGND, AGND, PAD) without the rest of the circuitry to test the SW signal with an oscilloscope?
3. What are some other considerations I should take when testing this on a bread board?