|
Internet Janitor posted:Hopefully this isn't too off-topic, but I'm helping to organize a little game jam that may be of interest to readers of this thread: This seems dope
|
#
¿
Sep 29, 2015 06:44
|
|
|
|
| # ¿ May 11, 2024 06:30 |
|
|
I'm working with a device with two STM32 devices, and I tested out creating a JTAG chain with them last week solely through the existing programming headers. It worked, so now I'm having a cable made up so I can do simultaneous debugging of these two processors. However, I'm running into a little confusion with regards to the nJTRST line---specifically, whether it needs a pull-up or a pull-down. My STM32 reference manual says that there is an internal pullup for that line (along with JTDI and JTMS), because the IEEE standard recommends pull ups on those lines. However, looking at other sources, they have pull-downs on nJTRST. Should I just leave my devices (with there internal nJTRST pull-ups) alone, or do I need to add an external pullup or pulldown? Also, can I safely ignore the nRESET signal from the JTAG connector? Both of my programming headers have nRESET (along with nJTRST), but I assume I only need that when I'm using Serial Wire debugging instead? I assume that I should be able to reset both CPUs via JTAG without any trouble. EDIT: I'm also somewhat confused by the numbering of devices in the JTAG scan chain. Different sources are giving me different ordering, so I can't figure out of JTDI goes to the *first* device or the *last* device. This is not super-relevant, except when it comes to making sure my jtag chain adapter cable has a properly terminated JTCK and an inline resistor on the proper point of JTDO. From http://www.xjtag.com/support-jtag/dft-guidelines.php :  And from the manual for my J-Link debugger (https://www.segger.com/admin/uploads/productDocs/UM08001_JLink.pdf):  From my temporary test setup last week, I ended up with JTDI connected to *my* device 0, and JTDO going to device 1. In the debugger, device 0 was setup with 0 preceeding bits, and device 1 was setup with 9 preceding bits (5 for the boundary scan TAP + 4 for the Cortex-M4 debug TAP). However, looking at the tech ref, it shows JTDI going into the boundary scan TAP first---does this mean my debugger is just reversing the order of the JTAG chain, so that instead of counting up from the device connected to JTDI, it counts down from the device connected to JTDO?  Slanderer fucked around with this message at 20:11 on Oct 12, 2015 |
|
#
¿
Oct 12, 2015 18:29
|
|
|
Anyone know how I can convince the IAR compiler to load two different applications onto the same processor with a debugger? Specifically, I have a boot loader application and a main application, which I manage as separate IAR projects, and load individually. For reasons not worth going into, the debugger is the only way to load either application right now, and I would like to ensure that people don't accidentally forget to update the bootloader by forcing it to be downloaded by the debugger every time. Anyone know if this is possible?
|
|
#
¿
Oct 16, 2015 20:05
|
|
|
This might be a better question for another thread, but I figure I might try here first: I'm on an AM335x-based platform running Linux, and I'm trying to get a splash screen to show up as early as possible (and stay up!). I was able to get the splash screen to show up in U-Boot (thanks to texas instruments-provided code), and also in the kernel (the hardest part of each was getting the image converted to the proper format lol). However, the screen turns off around the time u-boot loads the kernel / the kernel starts up and doesnt turn back on until the LCD controller driver is loaded up. The problem is that I know next-to-nothing about kernel startup and the device drivers (besides messing with some device tree stuff). Obviously something is getting reconfigured in a way I didn't expect, but I'm not sure what, and more importantly, I'm not sure how to even begin debugging this. In order for an image to be displayed, the following needs to be in place: 1. GPIO need to be configured (for multiple enable lines to devices) 2. LCD clock PLLs configured 3. LCD driver registers configured 4. IO for LCD signals setup 5. Image loaded into memory So at some point I'm losing one or more of these things, but I'm not sure what. On a non-linux embedded platform, I'd just set a breakpoint during init and check registers + break out a multimeter. Anyone experienced with embedded linux have any thoughts?
|
|
#
¿
Mar 29, 2018 23:35
|
|