Newer
Older
Description: There is no mechanism in place to handle EP0 OUT data transfers.
There are two aspects to this problem, neither are easy to fix
(only because of the number of drivers that would be impacted):
1. The class drivers only send EP0 write requests and these are
only queued on EP0 IN by this drivers. There is never a read
request queued on EP0 OUT.
2. But EP0 OUT data could be buffered in a buffer in the driver
data structure. However, there is no method currently
defined in the USB device interface to obtain the EP0 data.
Updates: (1) The USB device-to-class interface as been extended so
that EP0 OUT data can accompany the SETUP request sent to the
class drivers. (2) The logic in the STM32 F4 OTG FS device driver
has been extended to provide this data. Updates are still needed
to other drivers.
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
Here is an overview of the required changes:
New two buffers in driver structure:
1. The existing EP0 setup request buffer (ctrlreq, 8 bytes)
2. A new EP0 data buffer to driver state structure (ep0data,
max packetsize)
Add a new state:
3. Waiting for EP0 setup OUT data (EP0STATE_SETUP_OUT)
General logic flow:
1. When an EP0 SETUP packet is received:
- Read the request into EP0 setup request buffer (ctrlreq,
8 bytes)
- If this is an OUT request with data length, set the EP0
state to EP0STATE_SETUP_OUT and wait to receive data on
EP0.
- Otherwise, the SETUP request may be processed now (or,
in the case of the F4 driver, at the conclusion of the
SETUP phase).
2. When EP0 the EP0 OUT DATA packet is received:
- Verify state is EP0STATE_SETUP_OUT
- Read the request into the EP0 data buffer (ep0data, max
packet size)
- Now process the previously buffered SETUP request along
with the OUT data.
3. When the setup packet is dispatched to the class driver,
the OUT data must be passed as the final parameter in the
call.
Update 2013-9-2: The new USB device-side driver for the SAMA5D3
correctly supports OUT SETUP data following the same design as
per above.
Update 2013-11-7: David Sidrane has fixed with issue with the
STM32 F1 USB device driver. Still a few more to go before this
can be closed out.
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 array of pointers.
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 replace 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).
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
Title: LIBM INACCURACIES
Description: "..if you are writing something like robot control or
inertial navigation system for aircraft, I have found
that using the toolchain libmath is only safe option.
I ported some code for converting quaternions to Euler
angles to NuttX for my project and only got it working
after switching to newlib math library.
"NuttX does not fully implement IEC 60559 floating point
from C99 (sections marked [MX] in OpenGroup specs) so if
your code assumes that some function, say pow(), actually
behaves right for all the twenty or so odd corner cases
that the standards committees have recently specified,
you might get surprises. I'd expect pow(0.0, 1.0) to
return 0.0 (as zero raised to any positive power is
well-defined in mathematics) but I get +Inf.
"NuttX atan2(-0.0, -1.0) returns +M_PI instead of correct
-M_PI. If we expect [MX] functionality, then atan2(Inf, Inf)
should return M_PI/4, instead NuttX gives NaN.
"asin(2.0) does not set domain error or return NaN. In fact
it does not return at all as the loop in it does not
converge, hanging your app.
"There are likely many other issues like these as the Rhombs
OS code has not been tested or used that much. Sorry for not
providing patches, but we found it easier just to switch the
math library."
Ref: https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/7805
Status: Open
Priority: Low for casual users but clearly high if you need care about
these incorrect corner case behaviors in the math libraries.
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
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: 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
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: 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
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
Title: FAT LONG FILENAME COMPATIBILTY
Description: Recently there have been reports that file with long file
names created by NuttX don't have long file names when viewed
on Windows. The long file name support has been around for a
long time and I don't ever having seen this before so I am
suspecting that some evil has crept in.
Status: Open
Priority: Medium
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
Title: MISSING FILES IN NSH 'LS' OF A DIRECTORY
Description: I have seen cases where (1) long file names are enabled,
but (2) a short file name is created like:
nsh> echo "This is another thest" >/mnt/sdcard/another.txt
But then on subsequent 'ls' operations, the file does not appear:
nsh> ls -l /mnt/sdcard
I have determined that the problem is because, for some as-
of-yet-unkown reason the short file name is treated as a long
file name. The name then fails the long filename checksum
test and is skipped.
readdir() (and fat_readdir()) is the logic underlying the
failure and the problem appears to be something unique to the
fat_readdir() implementation. Why? Because the file is
visible when you put the SD card on a PC and because this
works fine:
nsh> ls -l /mnt/sdcard/another.txt
The failure does not happen on all short file names. I do
not understand the pattern. But I have not had the opportunity
to dig into this deeply.
Status: Open
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
Priority: Perhaps not a problem??? I have analyzed this problem and
I am not sure what to do about it. I am suspected that a
fat filesystem was used with a version of NuttX that does
not support long file name entries. Here is the failure
scenario:
1) A file with a long file name is created under Windows.
2) Then the file is deleted. I am not sure if Windows or
NuttX deleted the file, but the resulting directory
content is not compatible with NuttX with long file
name support.
The file deletion left the full sequence of long
file name entries intact but apparently delete only
the following short file name entry. I am thinking
that this might have happened because a version of NuttX
with only short file name support was used to delete
the file.
3) When a new file with a short file name was created, it
re-used the short file name entry that was previously
deleted. This makes the new short file name entry
look like a part of the long file name.
4) When comparing the checksum in the long file name
entry with the checksum of the short file name, the
checksum fails and the entire directlry sequence is
ignored by readder() logic. This the file does not
appear in the 'ls'.
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 NxTERM FONT CACHING
Description: Now each NxTerm instance has its own private font cache
whose size is determined by CONFIG_NXTERM_MXCHARS. If there
are multiple NxTerm instances using the same font, each will
have a separate font cache. This is inefficient and wasteful
of memory: Each NxTerm 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 NxTerm were to be used in a
product.
Title: NxTERM VT100 SUPPORT
Description: If the NxTerm will be used with the Emacs-like command line
Gregory Nutt
committed
editor (CLE), then it will need to support VT100 cursor control
commands.
Status: Open
Priority: Low, the need has not yet arisen.
Title: ANTI-ALIASING
Description: Needed for proper rendering. After some analysis, I believe
this change would only be required in the the trapezoid
rendering logic. Essentially, it would need to blend the
fractional pixels at ends of each run with the underlying
pixel.
Hmmm.. graphics are sometimes erased by just redrawing them
with the background color. Would this approach leave ghost
images around where the erase image was?
Status: Open
Priority: Medium-ish. This would definitely improve graphics rendering
and line drawing.
Title: PER-WINDOW FRAMEBUFFERS
Description: One of the most awkard things to handle in the NX windowing
system is the re-draw callback. This is difficult because it
requires ad hoc, custom logic to be able to do the redrawing
in most cases.
One solution would be to provide a per-window framebuffer.
All rending would be performed into the per-window framebuffer
and the rended bits would be copied the LCD or framebuffer
device memory on demand when the redraw is required.
This would (a) greatly simplify the graphics interface, (b)
greatly improve redraw performance, and (c) enable a more
generic use of the windowing. The downside would be a large
usage of memory to hold all of the framebuffers, one for each
window.
Status: Open
Priority: Low, of mostly strategic value.
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.
Title: PDBG
Description: Move the the pascal p-code debugger into the NuttX apps/ tree
where it can be used from the NSH command line.
Status: Open
Priority: Low
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: 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: 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: SIMULATOR HAS NO INTERRUPTS (NON-PREMPTIBLE)
Description: The current simulator implementation is has no interrupts and, hence,
is non-preemptible. Also, without simulated interrupt, there can
be no high-fidelity simulated device drivers.
Currently, all timing and serial input is simulated in the IDLE loop:
When nothing is going on in the simulation, the IDLE loop runs and
fakes timer and UART events.
Status: Open
Priority: Low, unless there is a need for developing a higher fidelity simulation
I have been thinking about how to implement simulated interrupts in
the simulation. I think a solution would work like this:
http://www.nuttx.org/doku.php?id=wiki:nxinternal:simulator
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: 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
Gregory Nutt
committed
Description: There is bit bit logic in 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: https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/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.
Title: IMPROVED TASK START-UP AND SYSCALL RETURN
Description: Couldn't up_start_task and up_start_pthread syscalls be
eliminated. Wouldn't this work to get us from kernel-
to user-mode with a system trap:
lda r13, #address
str rn, [r13]
msr spsr_SVC, rm
ld r13,{r15}^
Would also need to set r13_USER and r14_USER. For new
SYS_context_switch... couldn't we do he same thing?
Also... System calls use traps to get from user- to kernel-
mode to perform OS services. That is necessary to get from
user- to kernel-mode. But then another trap is used to get
from kernel- back to user-mode. It seems like this second
trap should be unnecessary. We should be able to do the
same kind of logic to do this.
Status: Open
Priority: Low-ish, but a good opportunity for performance improvement.
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;
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: 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 software bug.
Gregory Nutt
committed
o ARM/SAMA5D3 ((arch/arm/src/sama5/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Issues related to the SAMA5D3 port are in configs/sama5d3x-ek/README.txt.
Issues related to the SAMA5D4 port are in configs/sama5d4-ek/README.txt.
o ARM/SAMV7 ((arch/arm/src/samv7/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Issues related to the SAMA5D3 port are in configs/samv71-xult/README.txt.
Gregory Nutt
committed
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 architecture 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 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 ***
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.