Loading ...
Sorry, an error occurred while loading the content.

Re: [nuttx] Non-contagious RAMs in NuttX

Expand Messages
  • Freddie Chopin
    ... Indeed - I ve found the info I was looking for there - thx for pointing me to the right direction! I ve also found the info about LPC17xx (; So now a small
    Message 1 of 10 , Nov 1, 2012
    • 0 Attachment
      W dniu 2012-10-31 23:19, Gregory Nutt pisze:
      > Yes, it should be corrected. But that setting is not used on the STM32
      > 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.

      Indeed - I've found the info I was looking for there - thx for pointing
      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 because
      > it has to be an integer,not an expression.

      Sure - I used an expression to show what I mean (;

      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.

      4\/3!!
    • Freddie Chopin
      ... I ll check that out in a moment - thx again for info (; ... True - CCM is connected to D-Bus only, an you can execute instructions via I-Bus or S-Bus
      Message 2 of 10 , Nov 1, 2012
      • 0 Attachment
        W dniu 2012-10-31 23:31, Gregory N pisze:
        > 1) If you are allocating DMA buffers from the heap, then you have to
        > 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.

        I'll check that out in a moment - thx again for info (;

        > 2) When I was testing the ELF loader last week I discovered another
        > nasty thing about CCM: You can't execute code from it either. The Cortex
        > hardfaults fetching the first instruction.

        True - CCM is connected to D-Bus only, an you can execute instructions
        via I-Bus or S-Bus (probably) only.

        > 3) I am not convinced that you can safely do DMA from external 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...

        4\/3!!
      • Freddie Chopin
        ... Sorry, it s just a nickname (; But I actually learned to play piano some time ago (; 4 /3!!
        Message 3 of 10 , Nov 1, 2012
        • 0 Attachment
          W dniu 2012-10-31 23:51, Gregg Levine pisze:
          > What about music? (Yes we're going off topic here.) I noticed the last
          > name and wondered if you were part of the composer's family. I
          > certainly hope so, he's one of my favorites.

          Sorry, it's just a nickname (; But I actually learned to play piano some
          time ago (;

          4\/3!!
        • Gregory N
          ... I 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
          Message 4 of 10 , Nov 1, 2012
          • 0 Attachment
            > > 3) I am not convinced that you can safely do DMA from external 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...

            I 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).

            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.

            Greg
          Your message has been successfully submitted and would be delivered to recipients shortly.