3795 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:11:53 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=1021&page=3#post-6516 Thu, 22 Sep 2011 09:42:22 +0000 mbolivar 6516@http://forums.leaflabs.com/ <p>NF6X:</p> <p>You should know that the OpenOCD scripts provided with libmaple are only known to work with Maple. They make a few assumptions that aren't valid for Maple Native.</p> <p>In particular, check out the comment in support/openocd/flash_0.4.cfg that says "TODO: native". Note that the lines surrounding it are for different SRAM sizes, with the one that is commented out appropriate for the STM32F103ZE on Native.</p> <p>Also note that the lines after "Flashing image..." and "Verifying image..." refer to build/maple.bin. For Maple Native, these will be build/maple_native.bin.</p> <p>I'm sorry that we haven't updated these scripts to be more generic. If you are interested in helping us out on that, it would be very appreciated. Any patches can be emailed to <a href="mailto:info@leaflabs.com">info@leaflabs.com</a>, or you can just send us a pull request via <a href="https://github.com/leaflabs/libmaple">libmaple's github page</a>. </p> http://forums.leaflabs.com/topic.php?id=1021&page=3#post-6504 Wed, 21 Sep 2011 15:36:20 +0000 NF6X 6504@http://forums.leaflabs.com/ <p>I think I figured out my JTAG issue. If I'm correctly interpreting the OpenOCD documentation and the Maple Native schematic, then it appears that for Maple Native, I need to change the OpenOCD config files' reset configurations from "reset_config srst_only" to "reset_config trst_only". </p> http://forums.leaflabs.com/topic.php?id=1021&page=3#post-6498 Wed, 21 Sep 2011 14:41:42 +0000 kqr2 6498@http://forums.leaflabs.com/ <p>@NF6X : I would try upgrading to the latest version of OpenOCD (0.5.0). It adds support for a lot of newer parts. </p> http://forums.leaflabs.com/topic.php?id=1021&page=2#post-6495 Wed, 21 Sep 2011 13:59:27 +0000 NF6X 6495@http://forums.leaflabs.com/ <p>I'm trying to get the JTAG working on my Maple Native Beta now, using an Olimex ARM-USB-OCD and a 20-pin to 10-pin adapter made by TI and available through Digi-Key. This is my first time using the Olimex adapter and OpenOCD, so I hope I'm not asking any excessively lazy questions here! The adapter appears to be talking to the chip, but when I run "make install" from the current libmaple from the git repository, I get an error:</p> <p><code>~/Maple/libmaple% make install<br /> Install target: jtag<br /> support/scripts/openocd-wrapper.sh flash<br /> Open On-Chip Debugger 0.4.0 (2011-09-16-15:16)<br /> Licensed under GNU GPL v2<br /> For bug reports, read<br /> <a href="http://openocd.berlios.de/doc/doxygen/bugs.html" rel="nofollow">http://openocd.berlios.de/doc/doxygen/bugs.html</a><br /> 1000 kHz<br /> jtag_nsrst_delay: 100<br /> jtag_ntrst_delay: 100<br /> srst_only separate srst_gates_jtag srst_open_drain<br /> Info : clock speed 1000 kHz<br /> Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)<br /> Info : JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)<br /> Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints<br /> Halting...<br /> Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)<br /> Info : JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)<br /> Info : Halt timed out, wake up GDB.<br /> Error: timed out while waiting for target halted<br /> TARGET: stm32.cpu - Not halted<br /> Command handler execution failed<br /> make: *** [install] Error 1</code></p> <p>The failure appears to be happening when the OpenOCD config script issues a "reset halt" command, and I found some other post relating to "reset halt" not working with some Maple versions. Does anybody have any hints to share? </p> http://forums.leaflabs.com/topic.php?id=1021&page=2#post-6459 Tue, 20 Sep 2011 21:09:04 +0000 mbolivar 6459@http://forums.leaflabs.com/ <p>zouk: Thanks for the feedback. I can't speak to the silkscreen, but we'll at least add some helpful pictures in the documentation so future shield designers don't have the same problems. </p> http://forums.leaflabs.com/topic.php?id=1021&page=2#post-6457 Tue, 20 Sep 2011 21:03:00 +0000 mbolivar 6457@http://forums.leaflabs.com/ <p>gbulmer,</p> <blockquote><p> Maybe I have misunderstood, but the timing I look at for SRAM running at 55ns, looked able to support a lot quicker access than the 6MHz poslathian states. What am I missing? </p></blockquote> <p>To clarify, the ~6MHz figure is for writing to each 16-bit SRAM address in order using the unrolled loop given here:</p> <p><a href="https://github.com/leaflabs/libmaple/blob/v0.0.12/examples/test-fsmc.cpp#L64" rel="nofollow">https://github.com/leaflabs/libmaple/blob/v0.0.12/examples/test-fsmc.cpp#L64</a></p> <p>It is possible/likely that incrementing count is interfering with the timing.</p> <p>However, we're not going to get 55 ns regardless, because of some issues related to the FSMC clock, as follows.</p> <p>Here's the datasheet for the SRAM chip:</p> <p><a href="http://www.issi.com/pdf/62wv51216all.pdf" rel="nofollow">http://www.issi.com/pdf/62wv51216all.pdf</a></p> <p>Here's initSRAMChip(), the function responsible for configuring the SRAM chip in wirish/boards/maple_native.cpp:</p> <p><a href="https://github.com/leaflabs/libmaple/blob/v0.0.12/wirish/boards/maple_native.cpp#L189" rel="nofollow">https://github.com/leaflabs/libmaple/blob/v0.0.12/wirish/boards/maple_native.cpp#L189</a></p> <p>Advance warning: RM0008's FSMC docs are particularly bad.</p> <p>As specified in RM0008 section 21.5.4, the durations of phases within a memory transaction are multiples of HCLK, which in the case of the Maple Native is just SYSCLK (see <a href="https://github.com/leaflabs/libmaple/blob/v0.0.12/wirish/boards.cpp#L89">setupClocks()</a> in boards.cpp); i.e., in multiples of the 72 MHz clock's 13.9 ns. Since the AHB divider is its minimum value, and 72 MHz is the maximum clock rate, this is the smallest interval achievable on the STM32F103ZET6.</p> <p>Note that, for our FSMC configuration, EXTMOD is not set (so read and write timings are both controlled by the BTR; i.e., BWTR has no effect). It is possible that faster timing might be possible by setting EXTMOD and configuring reads and writes separately. I seem to recall thinking about it and coming to the conclusion that this wouldn't help, but I would be glad to be proven wrong. In any case, figures 189 and 190 give the relevant read and write waveforms, respectively.</p> <p>The relevant configuration of the FSMC in initSRAMChip() are the calls to fsmc_nor_psram_set_addset() and fsmc_nor_psram_set_datast(). The ADDSET bits are set to 0, corresponding to ADDSET duration of 1 HCLK cycle = 13.9 ns. This is the smallest possible duration supported by the FSMC. The DATAST bits are set to 3, corresponding to a DATAST duration of 4 HCLK cycles, or 55.6 ns. The other BTR bits are irrelevant (either don't care for SRAM or applicable only to other configurations).</p> <p>Let's now turn to the SRAM chip datasheet to see if DATAST may be reduced. Based on my reading of RM0008 fig. 190, the corresponding AC waveform is that given in "WRITE CYCLE NO. 1" on p. 10. Note that the WE signal must be held low for a time t_PWE, which, for the 55 ns part, must exceed 40 ns (see "WRITE CYCLE SWITCHING CHARACTERISTICS", p. 10). Turning back to fig. 190, it's clear that WE is held low for a duration equal to DATAST * 13.9 ns. Thus, the smallest value we can use is 3, and the timing we have is the best we can get.</p> <p>It's unfortunate that our basic unit of time is 13.9 ns; if it were different, we might be able to satisfy the t_PWE requirement without as much wasted time. Perhaps this indicates that the choice of SRAM chip wasn't the best one we could have made. </p> http://forums.leaflabs.com/topic.php?id=1021&page=2#post-6433 Tue, 20 Sep 2011 14:38:04 +0000 Zouk 6433@http://forums.leaflabs.com/ <p>poslathian: Okay, that makes sense. My thoughts though? Well, I had convinced a friend of mine here at my university to buy a board also. I noticed this shortly after mine came, and I brought it up when I was visiting his building at some point.</p> <p>We basically sat there for ten minutes counting pins, swearing, and not thinking about grounds. All in all it was a fun time, but we were really confused. Interesting that we didn't think of that, considering how we spend our spare time.</p> <p>I think it'd be good if there was some sort of indication on the silkscreen. Maybe (where "G" is Gnd, "N" is a pin number, and "o" is a pad):</p> <p>N o o o G -&gt; Where Gnd is on the right<br /> N o o o N -&gt; Where Gnd is in the middle (confusing! :D)<br /> G o o o N -&gt; Where Gnd is on the left</p> <p>This would at least form a system - though it still would require explanation.</p> <p>If it were my board to produce I'd probably just put a little circle around the pad on the silkscreen so that designers of the memory shield (I sat down to do this and then I realized this problem and decided to write my paper instead) at least know where the ground is before headers get soldered on.</p> <p>I feel like you guys probably thought of those two things though. And have a good reason not to do it that way. :P </p> http://forums.leaflabs.com/topic.php?id=1021&page=2#post-6431 Tue, 20 Sep 2011 14:06:49 +0000 gbulmer 6431@http://forums.leaflabs.com/ <p>mbolivar - so is it running at 6MHz, i.e. read two bytes at 6MHz?<br /> Maybe I have misunderstood, but the timing I look at for SRAM running at 55ns, looked able to support a lot quicker access than the 6MHz poslathian states. What am I missing? </p> http://forums.leaflabs.com/topic.php?id=1021&page=2#post-6427 Tue, 20 Sep 2011 13:16:53 +0000 mbolivar 6427@http://forums.leaflabs.com/ <blockquote><p> lowered the rate until it seemed to work 100%.</p> </blockquote> <p>slight correction: the FSMC config wasn't determined empirically. i chose it so that the timing would be as tight as possible while still being within the bounds given by the SRAM chip's datasheet, then we tested that reads/writes worked. see <a href="https://github.com/leaflabs/libmaple/blob/v0.0.12/examples/test-fsmc.cpp">examples/test-fsmc.cpp</a> in libmaple for the details.</p> <p>it's possible that tighter timing might still "work 100%", but we make no guarantees. </p> http://forums.leaflabs.com/topic.php?id=1021&page=2#post-6423 Tue, 20 Sep 2011 12:20:00 +0000 poslathian 6423@http://forums.leaflabs.com/ <p>nf6x - thanks for the note on the reflow. Thats not great news. Those damn can caps and the USB ports have been tricky to get right. </p> <p>gbulmer - by default the external RAM is configured to 6MHz, although I think it could probably go faster. We arrived at the number with a "write to every address and then read back" sketch, and lowered the rate until it seemed to work 100%. Note that the setup is sensitive to those exposed FSMC pins, so dont grab on to them while reading/writing. </p> <p>zouk - there are some ground pins scattered around the headers on Native. Since its such a big chip, there are quite a few grounds. We considered numbering the grounds, and then didnt. Making for somewhat awkward skips in the numbering. What do you think? </p> http://forums.leaflabs.com/topic.php?id=1021&page=2#post-6349 Wed, 14 Sep 2011 20:23:24 +0000 Zouk 6349@http://forums.leaflabs.com/ <p>What's up with the numbering on the FSMC header? Numbering on the board and in libmaple goes from 56-100 (45 pins), but there's 48 pins on that header on the physical device.</p> <p>What did I miss? </p> http://forums.leaflabs.com/topic.php?id=1021&page=2#post-6347 Wed, 14 Sep 2011 18:47:46 +0000 gbulmer 6347@http://forums.leaflabs.com/ <p>How fast is the access to the Maple Native's external RAM?<br /> The link that robodude666 poted is to 45ns and 55ns part, but what speed is the RAM+interface actually running at?<br /> I can imagine 18MHz (for a two byte access), is that correct? </p> http://forums.leaflabs.com/topic.php?id=1021&page=2#post-6346 Wed, 14 Sep 2011 15:13:31 +0000 NF6X 6346@http://forums.leaflabs.com/ <p>I got my board today. It looks good! One of the electrolytic caps had popped off in shipping. I re-soldered the cap without any trouble. Under the microscope, it looked like the solder paste flowed around the cap's leads properly but didn't adhere well enough. Maybe the reflow temperature profile wasn't right? I did not see any other damage to the board, cap or packing materials. I'm looking forward to playing with the board some more this weekend after my JTAG cable parts arrive from Digi-Key. </p> http://forums.leaflabs.com/topic.php?id=1021&page=2#post-6335 Tue, 13 Sep 2011 15:25:01 +0000 poslathian 6335@http://forums.leaflabs.com/ <p>so SDFat over SPI to the SD card happily exists, but the real thing to do on Maple Native is to use SDIO instead of SPI - a library for this would be awesome </p> http://forums.leaflabs.com/topic.php?id=1021&page=2#post-6333 Tue, 13 Sep 2011 14:23:16 +0000 Zouk 6333@http://forums.leaflabs.com/ <p>My boards came yesterday also. I've got grand plans for them... I just need to acquire a microSD card so that I can start figuring out accessing the card slot. Realized too late yesterday that I lacked one.</p> <p>I'm also excited to get started on a large memory bank; 1MB is nice but I've got my sights set on some pretty large datasets. Time for some datasheet reading. :D </p>