Maybe it will be possible to have an 'OAK' module for the Native.... Hmmm....
Maple Native Betas on sale tomorrow!
(33 posts) (10 voices)-
mbolivar
LeafLabsrobodude666:
Extensive documentation; Price TBA
It's still not released, according to the page =].
The blog post has updated specifications which should make it across to the rest of the site soon *cough*.
... and done :)
http://leaflabs.com/docs/hardware/maple-native-beta.html
Sorry about the old devices page living past its sell-by. We'll be moving all tech specs links to point to the official docs, which I try to be thorough about. Hopefully this will avoid some of the confusion that seems to have spread around the rest of the site.
Posted 4 years ago # -
Zouk
MemberMy 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.
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
Posted 4 years ago # -
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.
Posted 4 years ago # -
poslathian
LeafLabsnf6x - 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.
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.
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?
Posted 4 years ago # -
mbolivar
LeafLabslowered the rate until it seemed to work 100%.
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 examples/test-fsmc.cpp in libmaple for the details.
it's possible that tighter timing might still "work 100%", but we make no guarantees.
Posted 4 years ago # -
Zouk
Memberposlathian: 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.
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.
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):
N o o o G -> Where Gnd is on the right
N o o o N -> Where Gnd is in the middle (confusing! :D)
G o o o N -> Where Gnd is on the leftThis would at least form a system - though it still would require explanation.
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.
I feel like you guys probably thought of those two things though. And have a good reason not to do it that way. :P
Posted 4 years ago # -
mbolivar
LeafLabsgbulmer,
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?
To clarify, the ~6MHz figure is for writing to each 16-bit SRAM address in order using the unrolled loop given here:
https://github.com/leaflabs/libmaple/blob/v0.0.12/examples/test-fsmc.cpp#L64
It is possible/likely that incrementing count is interfering with the timing.
However, we're not going to get 55 ns regardless, because of some issues related to the FSMC clock, as follows.
Here's the datasheet for the SRAM chip:
http://www.issi.com/pdf/62wv51216all.pdf
Here's initSRAMChip(), the function responsible for configuring the SRAM chip in wirish/boards/maple_native.cpp:
https://github.com/leaflabs/libmaple/blob/v0.0.12/wirish/boards/maple_native.cpp#L189
Advance warning: RM0008's FSMC docs are particularly bad.
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 setupClocks() 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.
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.
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).
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.
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.
Posted 4 years ago # -
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:
~/Maple/libmaple% make install
Install target: jtag
support/scripts/openocd-wrapper.sh flash
Open On-Chip Debugger 0.4.0 (2011-09-16-15:16)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
1000 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
srst_only separate srst_gates_jtag srst_open_drain
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
Halting...
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
Info : Halt timed out, wake up GDB.
Error: timed out while waiting for target halted
TARGET: stm32.cpu - Not halted
Command handler execution failed
make: *** [install] Error 1The 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?
Posted 4 years ago #
Reply »
You must log in to post.