sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Fix some errors in stm32_allocateheap.c for STM32 F1 and F3 that crept in recently

Browse Source 
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@5776 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
patacongo 2013-03-22 18:26:03 +00:00
parent 6c6df1208f
commit eaee3fc423
9 changed files with 205 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
arch/arm/src/stm32/stm32_allocateheap.c
View File

@ -60,7 +60,7 @@
* following definitions must be provided to specify the size and
* location of internal(system) SRAM:
*
* SRAM1_END : End address (+1) of SRAM (F1 family only, the
* CONFIG_DRAM_END : End address (+1) of SRAM (F1 family only, the
* : F4 family uses the a priori end of SRAM)
*
* The F4 family also contains internal CCM SRAM. This SRAM is different
@ -90,7 +90,7 @@
#endif
/* For the STM312F10xxx family, all internal SRAM is in one contiguous block
* starting at g_idle_topstack and extending through SRAM1_END (my apologies for
* starting at g_idle_topstack and extending through CONFIG_DRAM_END (my apologies for
* the bad naming). In addition, external FSMC SRAM may be available.
*/
@ -98,7 +98,7 @@
/* Set the end of system SRAM */
# define SRAM1_END SRAM1_END
# define SRAM1_END CONFIG_DRAM_END
/* Check if external FSMC SRAM is provided */
@ -132,7 +132,7 @@
/* Set the end of system SRAM */
# define SRAM1_END SRAM1_END
# define SRAM1_END CONFIG_DRAM_END
/* Set the range of CCM SRAM as well (although we may not use it) */

44
configs/open1788/README.txt
View File

@ -346,6 +346,50 @@ CONFIGURATION
load objects twice to account for write failures. I have not yet
found a simple foolproof way to reliably get the code into FLASH.
4. Combining .hex files. If you plan to use the .hex files with your
debugger or FLASH utility, then you may need to combine the two hex
files into a single .hex file. Here is how you can do that.
a. The 'tail' of the nuttx.hex file should look something like this
(with my comments added):
$ tail nuttx.hex
# 00, data records
...
:10 9DC0 00 01000000000800006400020100001F0004
:10 9DD0 00 3B005A0078009700B500D400F300110151
:08 9DE0 00 30014E016D0100008D
# 05, Start Linear Address Record
:04 0000 05 0800 0419 D2
# 01, End Of File record
:00 0000 01 FF
Use an editor such as vi to remove the 05 and 01 records.
b. The 'head' of the nuttx_user.hex file should look something like
this (again with my comments added):
$ head nuttx_user.hex
# 04, Extended Linear Address Record
:02 0000 04 0801 F1
# 00, data records
:10 8000 00 BD89 01084C800108C8110208D01102087E
:10 8010 00 0010 00201C1000201C1000203C16002026
:10 8020 00 4D80 01085D80010869800108ED83010829
...
Nothing needs to be done here. The nuttx_user.hex file should
be fine.
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
file to produce a single combined hex file:
$ cat nuttx.hex nuttx_user.hex >combined.hex
Then use the combined.hex file with the to write the FLASH image.
If you do this a lot, you will probably want to invest a little time
to develop a tool to automate these steps.
nsh
---
Configures the NuttShell (nsh) located at examples/nsh. The

27
configs/open1788/scripts/memory.ld
View File

@ -34,15 +34,28 @@
****************************************************************************/
/* The LPC1788 has 512Kb of FLASH beginning at address 0x0000:0000 and
* 96Kb of total SRAM: 64Kb of SRAM in the CPU block beginning at address
* 0x10000000 and 32Kb of Peripheral SRAM in two banks, 8Kb at addresses
* 0x20000000 bank0 first and 8kb at 0x20002000 at bank0 second. And 16Kb
* 96KB of total SRAM: 64KB of SRAM in the CPU block beginning at address
* 0x10000000 and 32Kb of Peripheral SRAM in two banks, 8KB at addresses
* 0x20000000 bank0 first and 8KB at 0x20002000 at bank0 second. And 16KB
* at 0x20004000 on bank1.
*
* For MPU support, the kernel-mode NuttX section is assumed to be 64Kb of
* FLASH and 4Kb of SRAM. That, of course, can be optimized as needed (See
* also configs/open1788/scripts/kernel-space.ld). A detailed memory map
* for the CPU SRAM region is as follows:
* For MPU support, the kernel-mode NuttX section is assumed to be 64KB of
* FLASH and 4KB of SRAM. That, of course, can be optimized as needed (See
* also configs/open1788/scripts/kernel-space.ld).
*
* Alignment of the user space FLASH partition is a critical factor: The
* user space FLASH partition will be spanned with a single region of size
* 2**n bytes. The alignment of the user-space region must be the same. As
* a consequence, as the user-space increases in size, the alignmment
* requirement also increases.
*
* This alignment requirement means that the largest user space FLASH region
* you can have will be 256KB at it would have to be positioned at
* 0x00400000. If you change this address, don't forget to chagne the
* CONFIG_NUTTX_USERSPACE configuration setting to match and to modify
* the check in kernel/userspace.c.
*
* A detailed memory map for the 64KB CPU SRAM region is as follows:
*
* 0x10000 0000: Kernel .data region. Typical size: 0.1KB
* ------- ---- Kernel .bss region. Typical size: 1.8KB

48
configs/sam3u-ek/README.txt
View File

@ -419,8 +419,52 @@ must be is one of the following:
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
System.map - Symbols in the kernel-space ELF file
The J-Link programmer will except files in .hex, .mot, .srec, and .bin
formats.
The J-Link programmer will except files in .hex, .mot, .srec, and .bin
formats.
4. Combining .hex files. If you plan to use the .hex files with your
debugger or FLASH utility, then you may need to combine the two hex
files into a single .hex file. Here is how you can do that.
a. The 'tail' of the nuttx.hex file should look something like this
(with my comments added):
$ tail nuttx.hex
# 00, data records
...
:10 9DC0 00 01000000000800006400020100001F0004
:10 9DD0 00 3B005A0078009700B500D400F300110151
:08 9DE0 00 30014E016D0100008D
# 05, Start Linear Address Record
:04 0000 05 0800 0419 D2
# 01, End Of File record
:00 0000 01 FF
Use an editor such as vi to remove the 05 and 01 records.
b. The 'head' of the nuttx_user.hex file should look something like
this (again with my comments added):
$ head nuttx_user.hex
# 04, Extended Linear Address Record
:02 0000 04 0801 F1
# 00, data records
:10 8000 00 BD89 01084C800108C8110208D01102087E
:10 8010 00 0010 00201C1000201C1000203C16002026
:10 8020 00 4D80 01085D80010869800108ED83010829
...
Nothing needs to be done here. The nuttx_user.hex file should
be fine.
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
file to produce a single combined hex file:
$ cat nuttx.hex nuttx_user.hex >combined.hex
Then use the combined.hex file with the to write the FLASH image.
If you do this a lot, you will probably want to invest a little time
to develop a tool to automate these steps.
nsh:
Configures the NuttShell (nsh) located at examples/nsh. The

25
configs/sam3u-ek/scripts/memory.ld
View File

@ -33,17 +33,30 @@
*
****************************************************************************/
/* The AT91SAM3U-4 has 256Kb of FLASH beginning at address 0x0008:0000,
* 32Kb of SRAM beginning at address 0x2000:0000, and 16Kb of SRAM beginning
/* The AT91SAM3U-4 has 256KB of FLASH beginning at address 0x0008:0000,
* 32KB of SRAM beginning at address 0x2000:0000, and 16Kb of SRAM beginning
* at address 0x2008:000 (used only for heap). When booting from FLASH,
* FLASH memory is aliased to address 0x0000:0000 where the code expects to
* begin execution by jumping to the entry point in the 0x0800:0000 address
* range.
*
* For MPU support, the kernel-mode NuttX section is assumed to be 64Kb of
* FLASH and 4Kb of SRAM. That, of course, can be optimized as needed (See
* also configs/open1788/scripts/kernel-space.ld). A detailed memory map
* for the CPU SRAM region is as follows:
* For MPU support, the kernel-mode NuttX section is assumed to be 64KB of
* FLASH and 4KB of SRAM. That, of course, can be optimized as needed (See
* also configs/open1788/scripts/kernel-space.ld).
*
* Alignment of the user space FLASH partition is a critical factor: The
* user space FLASH partition will be spanned with a single region of size
* 2**n bytes. The alignment of the user-space region must be the same. As
* a consequence, as the user-space increases in size, the alignmment
* requirement also increases.
*
* This alignment requirement means that the largest user space FLASH region
* you can have will be 2128KB at it would have to be positioned at
* 0x000a0000. If you change this address, don't forget to chagne the
* CONFIG_NUTTX_USERSPACE configuration setting to match and to modify
* the check in kernel/userspace.c.
*
* A detailed memory map for the 16Kb SRAM region is as follows:
*
* 0x20000 0000: Kernel .data region. Typical size: 0.1KB
* ------- ---- Kernel .bss region. Typical size: 1.8KB

44
configs/stm32f4discovery/README.txt
View File

@ -1156,6 +1156,50 @@ Where <subdir> is one of the following:
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
System.map - Symbols in the kernel-space ELF file
4. Combining .hex files. If you plan to use the STM32 ST-Link Utility to
load the .hex files into FLASH, then you need to combine the two hex
files into a single .hex file. Here is how you can do that.
a. The 'tail' of the nuttx.hex file should look something like this
(with my comments added):
$ tail nuttx.hex
# 00, data records
...
:10 9DC0 00 01000000000800006400020100001F0004
:10 9DD0 00 3B005A0078009700B500D400F300110151
:08 9DE0 00 30014E016D0100008D
# 05, Start Linear Address Record
:04 0000 05 0800 0419 D2
# 01, End Of File record
:00 0000 01 FF
Use an editor such as vi to remove the 05 and 01 records.
b. The 'head' of the nuttx_user.hex file should look something like
this (again with my comments added):
$ head nuttx_user.hex
# 04, Extended Linear Address Record
:02 0000 04 0801 F1
# 00, data records
:10 8000 00 BD89 01084C800108C8110208D01102087E
:10 8010 00 0010 00201C1000201C1000203C16002026
:10 8020 00 4D80 01085D80010869800108ED83010829
...
Nothing needs to be done here. The nuttx_user.hex file should
be fine.
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
file to produce a single combined hex file:
$ cat nuttx.hex nuttx_user.hex >combined.hex
Then use the combined.hex file with the STM32 ST-Link tool. If
you do this a lot, you will probably want to invest a little time
to develop a tool to automate these steps.
nsh:
---
Configures the NuttShell (nsh) located at apps/examples/nsh. The

4
configs/stm32f4discovery/kernel/up_userspace.c
View File

@ -56,8 +56,8 @@
# error "CONFIG_NUTTX_USERSPACE not defined"
#endif
#if CONFIG_NUTTX_USERSPACE != 0x08018000
# error "CONFIG_NUTTX_USERSPACE must be 0x08018000 to match memory.ld"
#if CONFIG_NUTTX_USERSPACE != 0x08020000
# error "CONFIG_NUTTX_USERSPACE must be 0x08020000 to match memory.ld"
#endif
/****************************************************************************

2
configs/stm32f4discovery/kostest/defconfig
View File

@ -26,7 +26,7 @@ CONFIG_PASS1_TARGET="all"
CONFIG_PASS1_BUILDIR="configs/stm32f4discovery/kernel"
CONFIG_PASS1_OBJECT=""
CONFIG_NUTTX_KERNEL=y
CONFIG_NUTTX_USERSPACE=0x08018000
CONFIG_NUTTX_USERSPACE=0x08020000
#
# Binary Output Formats

34
configs/stm32f4discovery/scripts/memory.ld
View File

@ -36,19 +36,35 @@
/* The STM32F407VG has 1024Kb of FLASH beginning at address 0x0800:0000 and
* 192Kb of SRAM. SRAM is split up into three blocks:
*
* 1) 112Kb of SRAM beginning at address 0x2000:0000
* 2) 16Kb of SRAM beginning at address 0x2001:c000
* 3) 64Kb of CCM SRAM beginning at address 0x1000:0000
* 1) 112KB of SRAM beginning at address 0x2000:0000
* 2) 16KB of SRAM beginning at address 0x2001:c000
* 3) 64KB of CCM SRAM beginning at address 0x1000:0000
*
* When booting from FLASH, FLASH memory is aliased to address 0x0000:0000
* where the code expects to begin execution by jumping to the entry point in
* the 0x0800:0000 address
* range.
*
* For MPU support, the kernel-mode NuttX section is assumed to be 96Kb of
* FLASH and 4Kb of SRAM. That, of course, can be optimized as needed (See
* also configs/stm32f4discovery/scripts/kernel-space.ld). A detailed memory map
* for the CPU SRAM region is as follows:
* For MPU support, the kernel-mode NuttX section is assumed to be 128Kb of
* FLASH and 4Kb of SRAM. That is an excessive amount for the kernel which
* should fit into 64KB and, of course, can be optimized as needed (See
* also configs/stm32f4discovery/scripts/kernel-space.ld). Allowing the
* additional does permit addition debug instrumentation to be added to the
* kernel space without overflowing the partition.
*
* Alignment of the user space FLASH partition is also a critical factor:
* The user space FLASH partition will be spanned with a single region of
* size 2**n bytes. The alignment of the user-space region must be the same.
* As a consequence, as the user-space increases in size, the alignmment
* requirement also increases.
*
* This alignment requirement means that the largest user space FLASH region
* you can have will be 512KB at it would have to be positioned at
* 0x08800000. If you change this address, don't forget to chagne the
* CONFIG_NUTTX_USERSPACE configuration setting to match and to modify
* the check in kernel/userspace.c.
*
* A detailed memory map for the 112KB SRAM region is as follows:
*
* 0x20000 0000: Kernel .data region. Typical size: 0.1KB
* ------- ---- Kernel .bss region. Typical size: 1.8KB
@ -68,8 +84,8 @@ MEMORY
{
/* 1024Kb FLASH */
kflash (rx) : ORIGIN = 0x08000000, LENGTH = 96K
uflash (rx) : ORIGIN = 0x08018000, LENGTH = 928K
kflash (rx) : ORIGIN = 0x08000000, LENGTH = 128K
uflash (rx) : ORIGIN = 0x08020000, LENGTH = 896K
/* 112Kb of contiguous SRAM */