Newer
Older
Status: Open
Priority: High for class drivers that need EP0 data. For example, the
CDC/ACM serial driver might need the line coding data (that
Title: USB HUB SUPPORT
Description: Add support for USB hubs
Status: Open
Priority: Low/Unknown. This is a feature enhancement.
patacongo
committed
o Libraries (libc/)
^^^^^^^^^^^^^^^^^
Title: SIGNED time_t
Description: The NuttX time_t is type uint32_t. I think this is consistent
with all standards and with normal usage of time_t. However,
according to Wikipedia, time_t is usually implemented as a
signed 32-bit value.
Status: Open
Priority: Very low unless there is some compelling issue that I do not
know about.
Description: The definition of environ in stdlib.h is bogus and will not
work as it should. This is because the underlying
representation of the environment is not an arry of pointers.
Status: Open
Description: Need some minimal termios support... at a minimum, enough to
switch between raw and "normal" modes to support behavior like
that needed for readline().
patacongo
committed
UPDATE: There is growing functionality in libc/termios/ and in the
patacongo
committed
ioctl methods of several MCU serial drivers (stm32, lpc43, lpc17,
pic32). However, as phrased, this bug cannot yet be closed since
this "growing functionality" does not address all termios.h
functionality and not all serial drivers support termios.
Description: strftime() and other timing functions do not handle days of the week.
Status: Open
Priority: Low
Description: There is an issue with the way that getopt() handles errors that
return '?'.
1. Does getopt() reset its global variables after returning '?' so
that it can be re-used? That would be required to support where
the caller terminates parsing before reaching the last parameter.
2. Or is the client expected to continue parsing after getopt()
returns '?' and parse until the final parameter?
The current getopt() implementation only supports #2.
Status: Open
Priority: Low
Title: CONCURRENT STREAM READ/WRITE
Description: NuttX only supports a single file pointer so reads and writes
must be from the same position. This prohibits implementation
of behavior like that required for fopen() with the "a+" mode.
According to the fopen man page:
"a+ Open for reading and appending (writing at end of file).
The file is created if it does not exist. The initial file
position for reading is at the beginning of the file, but
output is always appended to the end of the file."
At present, the single NuttX file pointer is positioned to the
end of the file for both reading and writing.
Status: Open
Priority: Medium. This kind of operation is probably not very common in
deeply embedded systems but is required by standards.
Title: DIVIDE BY ZERO
Description: This is bug 3468949 on the SourceForge website (submitted by
Philipp Klaus Krause):
"lib_strtod.c does contain divisions by zero in lines 70 and 96.
AFAIK, unlike for Java, division by zero is not a reliable way to
get infinity in C. AFAIK compilers are allowed e.g. give a compile-
time error, and some, such as sdcc, do. AFAIK, C implementations
are not even required to support infinity. In C99 the macro isinf()
could replace the first use of division by zero. Unfortunately, the
macro INFINITY from math.h probably can't replce the second division
by zero, since it will result in a compile-time diagnostic, if the
implementation does not support infinity."
Status: Open
Priority:
patacongo
committed
Description: This implementation of dtoa in libc/stdio is old and will not
work with some newer compilers. See
http://patrakov.blogspot.com/2009/03/dont-use-old-dtoac.html
Status: Open
Priority: ??
Title: FLOATING POINT FORMATS
Description: Only the %f floating point format is supported. Others are accepted
but treated like %f.
Status: Open
Priority: Medium (this might important to someone).
Title: FLOATING POINT PRECISION
Description: A fieldwidth and precision is required with the %f format. If %f
is used with no format, than floating numbers will be printed with
a precision of 0 (effectively presented as integers).
Status: Open
Priority: Medium (this might important to someone).
o File system / Generic drivers (fs/, drivers/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NOTE: The NXFFS file system has its own TODO list at nuttx/fs/nxffs/README.txt
Description: At present, the CAN driver does not support the poll() method.
Status: Open
Priority: Low
Title: REMOVING PIPES AND FIFOS
Description: There is no way to remove a FIFO or PIPE created in the
pseudo filesystem. Once created, they persist indefinitely
and cannot be unlinked. This is actually a more generic
issue: unlink does not work for anything in the pseudo-
filesystem.
Status: Open, but partially resolved: pipe buffer is at least freed
when there are not open references to the pipe/FIFO.
Description: The ROMFS file system does not verify checksums on either
volume header on on the individual files.
Status: Open
Priority: Low. I have mixed feelings about if NuttX should pay a
performance penalty for better data integrity.
Title: SPI-BASED SD MULTIPLE BLOCK TRANSFERS
Description: The simple SPI based MMCS/SD driver in fs/mmcsd does not
yet handle multiple block transfers.
Status: Open
Priority: Medium-Low
Title: READ-AHEAD/WRITE BUFFER UNTESTED
Description: Block driver read-ahead buffer and write buffer support is
implemented but not yet tested.
Status: Open
Priority: Low
Title: SDIO-BASED SD READ-AHEAD/WRITE BUFFERING INCOMPLETE
Description: The drivers/mmcsd/mmcsd_sdio.c driver has hooks in place to
support read-ahead buffering and write buffering, but the logic
is incomplete and untested.
Status: Open
Priority: Low
Description: All drivers that support the poll method should also report
POLLHUP event when the driver is closedd.
Status: Open
Priority: Medium-Low
Description: When I enable CONFIG_RAMLOG_CONSOLE, the system does not come up
properly (using configuration stm3240g-eval/nsh2). The problem
may be an assertion that is occurring before we have a console.
Title : USE VFS TO MANAGE NAMED MESSAGE QUEUES AND NAMED SEMAPHORES
Gregory Nutt
committed
Description: Currently redundant namespace management logic is use for named
message queues and semaphores. Named semaphore management should
Gregory Nutt
committed
be consolidated in the VFS. Perhaps in /ipc/mqueue and /ipc/sem.
Status: Open
Priority: Low. Nothing is broken. This is an enhancement that would
improve the OS design and possibly reduce some FLASH usage
Gregory Nutt
committed
Title: UNIFIED DESCRIPTOR REPRESENTATION
Descripton: There are two separate ranges of descriptors for file and
socket descriptors: if a descriptor is in one range then it is
recognized as a file descriptor; if it is in another range
then it is recognized as a socket descriptor. These separate
descriptor ranges can cause problems, for example, they makes
dup'ing descriptors with dup2() problematic. The two groups
of descriptors are really indices into two separate tables:
On an array of file structures and the other an array of
socket structures. There really should be one array that
is a union of file and socket descriptors. Then socket and
file decriptors could lie in the same range.
Status: Open
Priority: Low
Title: DUPLICATE FAT FILE NAMES
Description: "The NSH and POSIX API interpretations about sensitivity or
insensitivity to upper/lowercase file names seem to be not
consistent in our usage - which can result in creating two
directories with the same name..."
Gregory Nutt
committed
Example using NSH:
nsh> echo "Test1" >/tmp/AtEsT.tXt
nsh> echo "Test2" >/tmp/aTeSt.TxT
nsh> ls /tmp
/tmp:
AtEsT.tXt
aTeSt.TxT
nsh> cat /tmp/aTeSt.TxT
Gregory Nutt
committed
nsh> cat /tmp/AtEsT.tXt
Gregory Nutt
committed
o Graphics subystem (graphics/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
See also the NxWidgets TODO list file for related issues.
Description: Testing of all APIs is not complete. See
http://nuttx.sourceforge.net/NXGraphicsSubsystem.html#testcoverage
Status: Open
Priority: Medium
Title: ITALIC FONTS / NEGATIVE FONT OFFSETS
Description: Font metric structure (in include/nuttx/nx/nxfont.h) should allow
negative X offsets. Negative x-offsets are necessary for certain
glyphs (and is very common in italic fonts).
For example Eth, icircumflex, idieresis, and oslash should have
offset=1 in the 40x49b font (these missing negative offsets are
NOTE'ed in the font header files).
Status: Open. The problem is that the x-offset is an unsigned bitfield
in the current structure.
Priority: Low.
patacongo
committed
Title: RAW WINDOW AUTORAISE
Description: Auto-raise only applies to NXTK windows. Shouldn't it also apply
to raw windows as well?
Status: Open
Priority: Low
Title: AUTO-RAISE DISABLED
Description: Auto-raise is currently disabled in NX multi-server mode. The
patacongo
committed
reason is complex:
- Most touchscreen controls send touch data a high rates
- In multi-server mode, touch events get queued in a message
queue.
- The logic that receives the messages performs the auto-raise.
But it can do stupid things after the first auto-raise as
patacongo
committed
I am thinking that auto-raise ought to be removed from NuttX
and moved out into a graphics layer (like NxWM) that knows
more about the appropriate context to do the autoraise.
Status: Open
Priority: Medium low
patacongo
committed
Title: IMPROVED NXCONSOLE FONT CACHING
Description: Now each NxConsole instance has its own private font cache
whose size is determined by CONFIG_NXCONSOLE_MXCHARS. If there
are multiple NxConsole instances using the same font, each will
have a separate font cache. This is inefficient and wasteful
of memory: Each NxConsole instance should share a common font
cache.
Status: Open
Priority: Medium. Not important for day-to-day testing but would be
a critical improvement if NxConsole were to be used in a
product.
Title: P-CODES IN MEMORY UNTESTED
Description: Need APIs to verify execution of P-Code from memory buffer.
Status: Open
Title: SMALLER LOADER AND OBJECT FORMAT
Description: Loader and object format may be too large for some small
memory systems. Consider ways to reduce memory footprint.
o Documentation (Documentation/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Title: DOCUMENT APIS USABLE FROM INTERRUPT HANDLERS
Description: Need to document which APIs can be used in interrupt
handlers (like mq_send and sem_post) and which cannot.
Status: Open
Priority: Low
Title: NUTTX CONFIGURATION TOOL
Description: Need a NuttX configuration tool. The number of configuration
settings has become quite large and difficult to manage manually.
patacongo
committed
Update: This task is essentially completed. But probably not for
all platforms and all features. When do we know that the feature
is complete and that we can switch to exclusive use of the tool?
Description: This effort is underway using MinGW-GCC and GNUWin32 tools
for (coreutils+make+grep+sed+uname). Current status:
1. configs/stm32f4discovery/winbuild - builds okay natively
2. configs/ez80f910200kitg - Can be reconfigured to build natively.
Requires some manual intervention to get a clean build.
See configs/ez80f910200kitg/README.txt.
Title: WINDOWS DEPENDENCY GENERATION
Description: Dependency generation is currently disabled when a Windows native
toolchain is used in a POSIX-like environment (like Cygwin). The
issue is that the Windows tool generates dependencies use Windows
path formatting and this fails with the dependency file (Make.dep)
is include). Perhaps the only issue is that all of the Windows
dependencies needed to be quoted in the Make.dep files.
Status: Open
Priority: Low -- unless some dependency-related build issues is discovered.
Title: SETENV.H
Description: Logic in most setenv.sh files can create the following problem
on many platforms:
$ . ./setenv.sh
basename: invalid option -- 'b'
Try `basename --help' for more information.
The problem is that $0 is the current running shell which may include
a dash in front:
$ echo $0
-bash
But often is just /bin/bash (and the problem does not occur. The fix
is:
-if [ "$(basename $0)" = "setenv.sh" ]; then
+if [ "$_" = "$0" ] ; then
Status: Open
Priority: Low. Use of setenv.sh is optional and most platforms do not have
this problem. Scripts will be fixed one-at-a-time as is appropriate.
Title: MAKE EXPORT LIMITATIONS
Description: The top-level Makefile 'export' target that will bundle up all of the
NuttX libraries, header files, and the startup object into an export-able
tarball. This target uses the tools/mkexport.sh script. Issues:
1. This script assumes the host archiver ar may not be appropriate for
non-GCC toolchains
2. For the kernel build, the user libraries should be built into some
libuser.a. The list of user libraries would have to accepted with
some new argument, perhaps -u.
Status: Open
Priority: Low.
o Linux/Cywgin simulation (arch/sim)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Title: SIMULATED SERIAL DRIVER
Description: The simulated serial driver has some odd behavior. It
will stall for a long time on reads when the C stdio buffers are
being refilled. This only effects the behavior of things like
fgetc(). Workaround: Set CONFIG_STDIO_BUFFER_SIZE=0, suppressing
all C buffered I/O.
Status: Open
Priority: Low (because the simulator is only a test/development platform)
Title: SIMULATOR NETWORKING SUPPORT
Description: I never did get networking to work on the sim Linux target. On Linux,
it tries to use the tap device (/dev/net/tun) to emulate an Ethernet
NIC, but I never got it correctly integrated with the NuttX networking.
NOTE: On Cygwin, the build uses the Cygwin WPCAP library and is, at
least, partially functional (it has never been rigorously tested).
Status: Open
Priority: Low (unless you want to test networking features on the simulation).
Title: ROUND-ROBIN SCHEDULING IN THE SIMULATOR
Description: Since the simulation is not pre-emptible, you can't use round-robin
scheduling (no time slicing). Currently, the timer interrupts are
"faked" during IDLE loop processing and, as a result, there is no
task pre-emption because there are no asynchronous events. This could
probably be fixed if the "timer interrupt" were driver by Linux
signals. NOTE: You would also have to implement irqsave() and
irqrestore() to block and (conditionally) unblock the signal.
Status: Open
Priority: Low
Title: NSH ISSUES ON THE SIMULATOR
Descripion: The NSH example has some odd behaviors. Mult-tasking -- for example,
execution of commands in background -- does not work normally. This
is due to the fact that NSH uses the system standard input for the
console. This means that the simulation is actually "frozen" all of
the time when NSH is waiting for input and background commands never
get the chance to run.
Status: Open
Priority: This will not be fixed. This is the normal behavior in the current
design of the simulator. "Real" platforms will behave correctly
because NSH will "sleep" when it waits for console inpu and other
tasks can run freely.
Description: In the NSH example, the host HOST echoes each command so after you
you enter a command, the command is repeated on the next line. This
is an artifact of the simulator only.
Status: Open
Priority: This will not be fixed. This is the normal behavior in the current
design of the simulator. "Real" platforms will behave correctly.
Title: IMPROVED ARM INTERRUPT HANDLING
Description: ARM interrupt handling performance could be improved in some
ways. One easy way is to use a pointer to the context save
This approach is already implemented for the ARM Cortex-M0,
Cortex-M3, Cortex-M4, and Cortex-A5 families. But still needs
to be back-ported to the ARM7 and ARM9 (which are nearly
identical to the Cortex-A5 in this regard). The change is
*very* simple for this architecture, but not implemented.
Status: Open. But complete on all ARM platforms except ARM7 and ARM9.
Priority: Low.
Title: IMPROVED ARM INTERRUPT HANDLING
Description: The ARM and Cortex-M3 interrupt handlers restores all registers
upon return. This could be improved as well: If there is no
context switch, then the static registers need not be restored
because they will not be modified by the called C code.
(see arch/sh/src/sh1/sh1_vector.S for example)
Status: Open
Priority: Low
Title: CORTEX-M3 STACK OVERFLOW
Description: There is bit bit logic inf up_fullcontextrestore() that executes on
return from interrupts (and other context switches) that looks like:
ldr r1, [r0, #(4*REG_CPSR)] /* Fetch the stored CPSR value */
msr cpsr, r1 /* Set the CPSR */
/* Now recover r0 and r1 */
ldr r0, [sp]
ldr r1, [sp, #4]
add sp, sp, #(2*4)
/* Then return to the address at the stop of the stack,
* destroying the stack frame
*/
ldr pc, [sp], #4
Under conditions of excessively high interrupt conditions, many
nested interrupts can occur just after the 'msr cpsr' instruction.
At that time, there are 4 bytes on the stack and, with each
interrupt, the stack pointer may increment and possibly overflow.
This can happen only under conditions of continuous interrupts.
See this email thread: http://tech.groups.yahoo.com/group/nuttx/message/1261
On suggested change is:
ldr r1, [r0, #(4*REG_CPSR)] /* Fetch the stored CPSR value */
msr spsr_cxsf, r1 /* Set the CPSR */
ldmia r0, {r0-r15}^
But this has not been proven to be a solution.
UPDATE: Other ARM architectures have a similer issue.
Priority: Low. The conditions of continuous interrupts is really the problem.
If your design needs continuous interrupts like this, please try
the above change and, please, submit a patch with the working fix.
patacongo
committed
Title: STACK ALIGNMENT IN INTERRUPT HANDLERS
Description: The EABI standard requires that the stack always have a 32-byte
alignment. There is no guarantee at present that the stack will be
so aligned in an interrupt handler. Therefore, I would expect some
issues if, for example, floating point or perhaps long long operations
were performed in an interrupt handler.
This issue exists for ARM7, ARM9, Cortex-M0, Cortex-M3, and
Cortex-M4 but has been addressed for the Cortex-A5. The fix
is really simple can cannot be incorporated without some
substantial testing. For ARM, the fix is the following logic
arround each call into C code from assembly:
mov r4, sp /* Save the SP in a preserved register */
bl cfunction /* Call the C function */
mov sp, r4 /* Restore the possibly unaligned stack pointer */
This same issue applies to the interrupt stack which is, I think
improperly aligned in almost all cases (except Cortex-A5).
Status: Open
Priority: Low for me because I never do floating point operations in
interrupt handlers.
o ARM/C5471 (arch/arm/src/c5471/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: UART re-configuration is untested and conditionally compiled out.
Status: Open
Priority: Medium. ttyS1 is not configured, but not used; ttyS0 is configured
by the bootloader
o ARM/DM320 (arch/arm/src/dm320/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: config/ntos-dm320: It seems that when a lot of debug statements
are added, the system no longer boots. This is suspected to be
a stack problem: Making the stack bigger or removing arrays on
the stack seems to fix the problem (might also be the
bootloader overwriting memory)
Status: Open
Title: USB DEVICE DRIVER UNTESTED
Description: A USB device controller driver was added but has never been tested.
Status: Open
Priority: Medium
Title: FRAMEBUFFER DRIVER UNTESTED
Description: A framebuffer "driver" was added, however, it remains untested.
Status: Open
Priority: Medium
Description: In order to use the framebuffer "driver" additional video encoder
logic is required to setup composite video output or to interface
with an LCD.
Status: Open
Priority: Medium (high if you need to use the framebuffer driver)
o ARM/i.MX (arch/arm/src/imx/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: The basic port of the i.MX1 architecture was never finished. The port
is incomplete (as of this writing, is still lacks a timer, interrupt
decoding, USB, network) and untested.
Title: SPI METHODS ARE NOT THREAD SAFE
Description: SPI methods are not thread safe. Needs a semaphore to protect from re-entrancy.
Status: Open
Priority: Medium -- Will be very high if you do SPI access from multiple threads.
o ARM/LPC17xx (arch/arm/src/lpc17xx/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: USB DMA not fully implemented. Partial logic is in place but it is
fragmentary and bogus. (Leveraged from the lpc214x)
Title: SSP DRIVER IMPROVEMENTS
Description: a) At present the SSP driver is polled. Should it be interrupt driven?
Look at arch/arm/src/imx/imx_spi.c -- that is a good example of an
interrupt driven SPI driver. Should be very easy to part that architecture
to the LPC.
b) See other SSP (SPI) driver issues listed under ARM/LPC214x. The LPC17xx
driver is a port of the LPC214x driver and probably has the same issues.
b) Other SSP driver improvements: Add support for multiple devices on the
SSP bus, use DMA data transfers
Status: Open
Priority: Medium
Title: NOKIA LCD DRIVER NONFUNCTIONAL
Description: An LCD driver for the Olimex LPC1766STK has been developed. However, that
driver is not yet functional on the board: The backlight comes on, but
nothing is visible on the display.
Status: Open
Priority: Medium-Low (unless you need the display on the LPC1766STK!)
o ARM/LPC214x (arch/arm/src/lpc214x/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: Should use Vector Interrupts
Status: Open
Priority: Low
Description: USB DMA not fully implemented. Partial logic is in place but it is
fragmentary and bogus.
Title: USB SERIAL DRIVER REPORTS WRONG ERROR
Description: USB Serial Driver reports wrong error when opened before the
USB is connected (reports EBADF instead of ENOTCONN)
Status: Open
Priority: Low
Title: SPI DRIVER IMPROVEMENTS
Description: At present the SPI driver is polled. Should it be interrupt driven?
Look at arch/arm/src/imx/imx_spi.c -- that is a good example of an
interrupt driven SPI driver. Should be very easy to part that architecture
to the LPC.
Title: SPI METHODS ARE NOT THREAD SAFE
Description: SPI methods are not thread safe. Needs a semaphore to protect from re-entrancy.
Status: Open
Priority: Medium -- Will be very high if you do SPI access from multiple threads.
Description: At present the SPI driver is polled -AND- there is a rather large, arbitrary,
delay in one of the block access routines. The purpose of the delay is to
avoid a race conditions. This begs for a re-design -OR- at a minimum, some
Desription: I am unable to initialize a 2Gb SanDisk microSD card (in adaptor) on the
the mcu123 board. The card fails to accept CMD0. Doesn't seem like a software
issue, but if anyone else sees the problem, I'd like to know.
Related: Fixes were recently made for the SDIO-based MMC/SD driver to
support 2Gb cards -- the block size was forced to 512 in all cases. The SPI-
based driver may also have this problem (but I don't think this would have
Title: USB BROKEN?
Description: I tried to bring up the new configuration at configs/mcu123-214x/composite,
and Linux failed to enumerate the device. I don't know if this is
a problem with the lpc214x USB driver (bit rot), or due to recent
changed (e.g., -r4359 is suspicious), or an incompatibility between the
Composite driver and the LPC214x USB driver. It will take more work
to find out which -- like checking if the other USB configurations are
also broken.
Status: Open
Priority: It would be high if the LPC2148 were a current, main stream architecture.
I am not aware of anyone using LPC2148 now so I think the priority has
to be low.
o ARM/LPC31xx (arch/arm/src/lpc31xx/)
Title: PLATFORM-SPECIFIC LOGIC
Description: arch/arm/src/lpc313x/lpc313x_spi.c contains logic that is specific to the
Embedded Artist's ea3131 board. We need to abstract the assignment of SPI
chip selects and logic SPI functions (like SPIDEV_FLASH). My thoughts are:
- Remove lpc313x_spiselect and lpc313x_spistatus from lpc313x_internal.h
- Remove configs/ea3131/src/up_spi.c
- Add configurations CONFIG_LPC3131x_CSOUT1DEV, CONFIG_LPC3131x_CSOUT2DEV,
and CONFIG_LPC3131x_CSOUT3DEV that maps the lpc313x SPI chip selects to
SPIDEV_* values.
- Change arch/arm/src/lpc313x/lpc313x_spi.c to use those configuration
settings.
Status: Open
Priority: High if you want to use SPI on any board other than the ea3131.
Description: arch/arm/src/lpc313x/lpc313x_spi.c may or may not be functional. It was
reported to be working, but I was unable to get it working with the
Atmel at45dbxx serial FLASH driver.
Status: Open
Priority: High if you need to use SPI.
o ARM/LPC43x (arch/arm/src/lpc43xx/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
o ARM/STR71x (arch/arm/src/str71x/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: Verify SPI driver and integrate with MMC support. This effort is stalled
at the moment because the slot on the Olimex board only accepts MMC card;
Description: Develop a USB driver and integrate with existing USB serial and storage
class drivers.
Title: SPI METHODS ARE NOT THREAD SAFE
Description: SPI methods are not thread safe. Needs a semaphore to protect from re-entrancy.
Status: Open
Priority: Medium -- Will be very high if you do SPI access from multiple threads.
patacongo
committed
o ARM/LM3S6918 (arch/arm/src/lm/)
Description: Still need to implement I2C
Description: Should terminate SSI/SPI transfer if an Rx FIFO overrun occurs.
Right now, if an Rx FIFO overrun occurs, the SSI driver hangs.
Status: Open
Priority: Medium, If the transfer is properly tuned, then there should not
be any Rx FIFO overruns.
Description: There are some lingering bugs in THTTPD, possibly race conditions. This
is covered above under Network Utilities, but is duplicated here
to point out that the LM3S suffers from this bug.
Status: Open.
UPDATE: I have found that increasing the size of the CGI program stack
from 1024 to 2048 (on the LM3S) eliminates the problem. So the most
likely cause is probably a stack overflow, not a hard sofware bug.
Priority: Probably Low
Gregory Nutt
committed
o ARM/SAMA5D3 ((arch/arm/src/sama5/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Issues related to the SAMA5D3 port are in configs/sama5d3x-ek/README.txt.
o ARM/STM32 (arch/arm/src/stm32/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description A USB device-side driver is in place but not well tested. At
present, the apps/examples/usbserial test sometimes fails. The situation
that causes the failure is:
- Host-side of the test started after the target side sends the
first serial message.
The general failure is as follows:
- The target message pends in the endpoint packet memory
- When the host-side of the test is stated, it correctly
reads this pending data.
- an EP correct transfer interrupt occurs and the next
pending outgoing message is setup
- But, the host never receives the next message
If the host-side driver is started before the first target message
is sent, the driver works fine.
Status: Open
Priority: Medium-High
Title: DMA EXTENSIONS F1/3
Description: DMA logic needs to be extended. DMA2, Channel 5, will not work
because the DMA2 channels 4 & 5 share the same interrupt.
Status: Open
Priority: Low until someone needs DMA1, Channel 5 (ADC3, UART4_TX, TIM5_CH1, or
TIM8_CH2).
Title: F4 SDIO MULTI-BLOCK TRANSFER FAILURES
Description: If you use a large I/O buffer to access the file system, then the
MMCSD driver will perform multiple block SD transfers. With DMA
ON, this seems to result in CRC errors detected by the hardware
patacongo
committed
during the transfer. Workaround: CONFIG_MMCSD_MULTIBLOCK_DISABLE=y.
Status: Open
Priority: Medium
Title: DMA BOUNDARY CROSSING
Description: I see this statement in the reference manual: "The burst
configuration has to be selected in order to respect the AHB protocol,
where bursts must not cross the 1 KB address boundary because the
minimum address space that can be allocated to a single slave
is 1 KB. This means that the 1 KB address boundary should not be crossed
by a burst block transfer, otherwise an AHB error would be generated,
that is not reported by the DMA registers."
The implication is that there may be some unenforced alignment
requirements for some DMAs. There is nothing in the DMA driver to
prevent this now.
Status: Open
Priority: Low (I am not even sure if this is a problem yet).
Title: DMA FROM EXTERNAL, FSMC MEMORY
Description: I have seen a problem on F1 where all SDIO DMAs work exist for
write DMAs from FSMC memory (i.e., from FSMC memory to SDIO).
Read transfers work fine (SDIO to FSMC memory). The failure is
a data underrun error with zero bytes of data transferred. The
workaround for now is to use DMA buffers allocated from internal
SRAM.
Status: Open
Priority: Low
Title: AMBER WEB SERVER UNTESTED
Description: There is a port for the Amber Web Server ATMega128, however this is
completely untested due to the lack to compatible, functional test
equipment.
Status: Open
Priority: The priority might as well be low since there is nothing I can do about
it anyway.
Description: Many printf-intensive examples (such as the OS test) cannot be executed
on most AVR platforms. The reason is because these tests/examples
generate a lot of string data. The build system currently places all
string data in RAM and the string data can easily overflow the tiny
SRAMs on these parts. A solution would be to put the string data
into the more abundant FLASH memory, but this would require modification
to the printf logic to access the strings from program memory.
Priority: Low. The AVR is probably not the architecuture that you want to use
for extensive string operations.
Title: SPI AND USB DRIVERS UNTESTED
Description: An SPI driver and a USB device driver exist for the AT90USB (as well
as a USB mass storage example). However, this configuration is not
fully debugged as of the NuttX-6.5 release.
Update 7/11: (1) The SPI/SD driver has been verified, however, (2) I
believe that the current teensy/usbmsc configuration uses too
much SRAM for the system to behave sanely. A lower memory footprint
version of the mass storage driver will be required before this can
be debugged
Status: Open
Priority: Medium-High.
Title: AVR32 PORT IS NOT FULLY TESTED
Description: A complete port for the AVR32 is provided and has been partially
debugged. There may still be some issues with the serial port
driver.
Status: Open
Priority: Medium
o 8051 / MCS51 (arch/8051/)
^^^^^^^^^^^^^^^^^^^^^^^^^
Title: STACK OVERFLOWS DURING INTERRUPT HANDLING
Description: Current status:
- Basic OS task management seems OK
- Fails when interrupts enabled. The stack pointer is around
0x6e before the failure occurs. It looks like some issue
when the stack pointer moves from the directly to indirectly
addressable region (0x80 boundary).
- Work on the 8052 is temporarily on hold
Status: Open
Priority: Low, 8051 is a tough platform because of the tiny stack.
Title: TIMER 0 AS SYSTEM TIMER
Description: Use timer 0 as system timer. Timer 2 is needed for second UART.
Logic is implemented, but there needs to be a system
configuration to change the ticks-per-second value to match the
timer interrupt rate
Status: Open
Priority: Low
Description: During build, there are several integer overflows reported:
sched/gmtime_r.c aroud lines 184 and 185
sched/clock_initialize.c at line 107
sched/pthread_create.c at 330
apps/examples/ostest/barrier.c around lines 53 and 74
apps/examples/ostest/sighand.c at 225 and 244
patacongo
committed
Status: Open. Update: These were reviewed during the hcs12 port. The
hcs12 also has 16-bit integer types (if -mshort is in the CFLAGS).
I believe that the warnings in most of the above have been fixed
but this has not been verified on this platform).
Description Global data is not being initialized. Logic like that of SDCCs
crt0*.s needs to be incorporated into the system boot logic
Status: Open
Priority: Low -- only because there as so many other issues with 8051
Title: 8051 BUILD BROKEN
Description: The last time I tried to build the pjrc-8051 configuration using
the SDCC 3.2.1 toolchain (for Windows). I got compilation
errors in sched/os_bringup.c. It complained about type
mis-matches. What I gather from Googling, this is a problem
with the --stack-auto option. At any rate, this problem will
need to be fixed if you want to resurrect the 8051 NuttX port.
Status: Open
Priority: Low -- I don't think anyone uses the 8051 port.
o MIPS/PIC32(arch/mips)
^^^^^^^^^^^^^^^^^^^^^
Title: PIC32 USB DRIVER DOES NOT WORK WITH MASS STORAGE CLASS
patacongo
committed
UPDATE: ** ONLY USING RAM DISK FOR EXPORTED VOLUME ***
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
Description: The PIC32 USB driver either crashes or hangs when used with
the mass storage class when trying to write files to the target
storage device. This usually works with debug on, but does not
work with debug OFF (implying some race condition?)
Here are some details of what I see in debugging:
1. The USB MSC device completes processing of a read request
and returns the read request to the driver.
2. Before the MSC device can even begin the wait for the next
driver, many packets come in at interrupt level. The MSC
device goes to sleep (on pthread_cond_wait) with all of the
read buffers ready (16 in my test case).
3. The pthread_cond_wait() does not wake up. This implies
a problem with pthread_con_wait(?). But in other cases,
the MSC device does wake up, but then immediately crashes
because its stack is bad.
4. If I force the pthread_cond_wait to wake up (by using
pthread_cond_timedwait instead), then the thread wakes
up and crashes with a bad stack.
So far, I have no clue why this is failing.
patacongo
committed
UPDATE: This bug was recorded using the PIC32 Ethernet
Starter kit with a RAM disk (that board has no SD card slot).
patacongo
committed
Mikroelektronika using a real SD card, there is no such
problem -- the mass storage device seems quite stable.
UPDATE: Hmmm.. retesting with the Mikroelektronika board
shows problems again. I think that there are some subtle
timing bugs whose effects can very from innocuous to severe.
patacongo
committed
Status: Open
Priority: Originally, High BUT reduced to very Low based on the
UPDATED comments.
Title: PIC32 USB MASS STORAGE DEVICE FAILS TO RE-CONNECT
Description: Found using configuration configs/pic32mx7mmb/nsh.
In this configuratin, the NSH 'msconn' command will connect the
mass storage device to the host; the 'msdis' command will
disconnect the device. The first 'msconn' works perfectly.
However, when attempting to re-connect, the second 'msconn'
command does not command properly: Windows reports an
unrecognized device. Apparently, some state is being properly
reset when the mass storage device is disconnected. Shouldn't
be hard to fix.
patacongo
committed
Priority: Medium
Title: POSSIBLE INTERRUPT CONTROL ISSUE
Description: There is a kludge in the file arch/mips/src/common/up_idle.c.
Basically, if there is nothing else going on in the IDLE loop,
you have to disable then re-enable interrupts. Logically nothing
changes, but if you don't do this interrupts will be be disabled
in the IDLE loop which is a very bad thing to happen.
Some odd behavior in the interrupt setup on the IDLE loop is
not really a big concern, but what I do not understand is if
this behavior is occurring on all threads after all context
switches: Are interrupts always disabled until re-enabled?
This requires some further investigation at some point; it
may be nothing but may also be a symptom of some changes
required to the interrupt return logic (perhaps some CP0
status hazard?)
Status: Open
Priority: Low. Puzzling and needs some investigation, but there there
is no known misbehavior.
o Hitachi/Renesas SH-1 (arch/sh/src/sh1)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: There are instabilities that make the SH-1 port un-usable. The
nature of these is not understood; the behavior is that certain SH-1
instructions stop working as advertised. I have seen the following
examples:
412b jmp @r1 - Set a return address in PR, i.e., it behaved like
410b jsr @r1. Normally 412b works correctly, but in the failure
condition, it reliably set the PR.
69F6 mov.l @r15+,r9 - wrote the value of R1 to @r15+. This behavior
does not correspond to any known SH-1 instruction
This could be a silicon problem, some pipeline issue that is not
handled properly by the gcc 3.4.5 toolchain (which has very limit
SH-1 support to begin with), or perhaps with the CMON debugger. At
any rate, I have exhausted all of the energy that I am willing to put
into this cool old processor for the time being.
Update: This bug will probably never be addressed now. I just
cleaned house and my old SH-1 was one of the things that went.
Status: Open
Priority: Low -- because the SH-1, SH7032, is very old and only of historical