Re: [nuttx] Non-contagious RAMs in NuttX
- W dniu 2012-10-31 23:19, Gregory Nutt pisze:
> Yes, it should be corrected. But that setting is not used on the STM32Indeed - I've found the info I was looking for there - thx for pointing
> anyway (which is, of course, why it works with the wrong memory size).
> The memory allocation is done in
> arch/arm/src/stm32/stm32_allocateheap.c. That answer to all to all of
> your following questions is in that file too.
me to the right direction! I've also found the info about LPC17xx (;
So now a small offtopic. NuttX is HUGE - there are lots of files, lots
of configuration options, lots of possibilities. Of course that's good!
But - and I hope you don't get offended or sth - the documentation for
this project doesn't fit very well - there is info in source/header
files, but the first place many people go is the documentation on
homepage. That's why I'd like to suggest Doxygen for main nuttx source
again - it will be much easier to browse (everything is included,
cross-referenced and with option to see the relevant source fragment if
no description is given) and always up-to-date (if the comments in the
source code are up-to-date, but there's no reason to assume the
opposite). It doesn't need to be a one-step change, but gradually we
(I'd help of course) could include more and more pieces in Doxygen,
moving info from HTML docs to sourcefiles (where relevant).
> Good idea. I'll do that, but I'll have to use the value 114688 becauseSure - I used an expression to show what I mean (;
> it has to be an integer,not an expression.
So - thx again for directions (; And thx for the project - it seems that
whenever I think of something that is usually not handled in other
projects (or sth that may be complex, non-standard, etc.) you already
got that figured out and working (;
BTW - in stm32_allocateheap.c you assume that for STM32F2 and STM32F4
firt SRAM region (usually 112kB) is contiguous with the second 16kB
region at 0x2001c000, but STM32F2 that have less than 128kB don't have
these regions adjacent (the configurations are 48 + 16 and 80 + 16, 16kB
always at 0x2001c000). That's just a sidenote for future porting efforts.
- W dniu 2012-10-31 23:31, Gregory N pisze:
> 1) If you are allocating DMA buffers from the heap, then you have toI'll check that out in a moment - thx again for info (;
> exclude CCM because there is no way of knowing which memory malloc is
> going to give you.
> I created a special allocator just for different memory (like CCM). This
> is granule allocator that you can find in mm/*. See nuttx/mm/README.txt.
> 2) When I was testing the ELF loader last week I discovered anotherTrue - CCM is connected to D-Bus only, an you can execute instructions
> nasty thing about CCM: You can't execute code from it either. The Cortex
> hardfaults fetching the first instruction.
via I-Bus or S-Bus (probably) only.
> 3) I am not convinced that you can safely do DMA from external FSMC SRAMLooking at the bus matrix picture from the manual I don't see any reason
> either. I worked with someone a month or so ago and found that the SDIO
> dma failed when trying to DMA "from" FSMC SRM (ie., writing to SDIO).
> Reading worked fine.
> There might be some kind of subtle DMA setup or FSMC setup that could
> fix this, but I didn't have the wherewithal to solve it.
why this should not work. The FSMC controller has connection points with
every internal bus in the core, including the DMA buses... FSMC
configuration in STM32 is very complicated and not documented clearly so
I guess that the problem must be somewhere there...
- W dniu 2012-10-31 23:51, Gregg Levine pisze:
> What about music? (Yes we're going off topic here.) I noticed the lastSorry, it's just a nickname (; But I actually learned to play piano some
> name and wondered if you were part of the composer's family. I
> certainly hope so, he's one of my favorites.
time ago (;
> > 3) I am not convinced that you can safely do DMA from external FSMC SRAMI suspect that you are right. I suspect that FSMC DMA works. However, in my case, DMA reads and writes would work fine until malloc() return a buffer in FSMC SRAM. Then only DMA reads worked (i.e., SDIO to FSMC SRAM).
> > either. I worked with someone a month or so ago and found that the SDIO
> > dma failed when trying to DMA "from" FSMC SRM (ie., writing to SDIO).
> > Reading worked fine.
> > There might be some kind of subtle DMA setup or FSMC setup that could
> > fix this, but I didn't have the wherewithal to solve it.
> Looking at the bus matrix picture from the manual I don't see any reason
> why this should not work. The FSMC controller has connection points with
> every internal bus in the core, including the DMA buses... FSMC
> configuration in STM32 is very complicated and not documented clearly so
> I guess that the problem must be somewhere there...
DMA writes (i.e., from SRAM to SDIO) always failed with a data under-run error and zero bytes transferred. The DMA setup was the same as for internal SRAM so I suspected the FSMC setup.