SGS-THOMSON Microelectronics
ST20450A Customer Bug List
Compiled by Ian Griffin
ST20 Technical Marketing
Created on : November 18, 1996
Last Revised on : 23/10/97
Using analyse pin does not clear the error flag, so on exit from analyse when the error flag and pin have been set,the processor will halt on error again and cannot be rerun.
Use the toolset to clear the halt on error mode flag before
running the program and then after analysing, test the error
flag to clear it, before restarting.
When rasedge is programmed to be one phase, the edge comes out after zero phases, i.e. in this case the rasedge value least significant bit is ignored.
MemReq input signal is not synchronised and therefore should be specified in the datasheet as a synchronous signal not an asynchronous signal. It should obey the setup and hold times as specified in section 16, Timing Specifications. ( Table 16.1 page 81 )
This bug affects the following instructions: move devmove move2d move2dzero move2dnonzero out (soft channel only)
For the bug to occur an micro code interrupt must arrive after the instruction has started but before the first read from memory has been issued onto the internal bus. The source and destination of the data to be moved must be aligned such that two initial reads (to consecutive word addresses) are required to obtain enough bytes for the first word write and the last move" instruction must have performed an odd number of writes.
NOTE: Moves with aligned source data are always safe and therefore this bug is not likely to be encountered. move2d instructions need to be considered to be as a set of moves each move may invoke the problem unless the source is aligned.
Micro code interrupt in this case occurs when either a scheduling event, i.e. process becomes ready to run or is run, or an interrupt.
Avoid the use of unaligned soft channel out instructions by padding data if necessary at the front of a message.
Avoid other unaligned "move" instructions.
If an unaligned "move" is required then there are
three possible
workarounds:
1) Disable micro interrupts around the "move"
2) Break the "move" into two move instructions, the first to move the unaliged bytes (until a word boundary is reached at the source) and then a second, word aligned, move to complete the operation.
3) Replace the "move" by a sequence of load and stores to move the data.
Workaround two is being implemented as new memcpy and memmove C library functions and is available from SGS-THOMSON.
If a micro interrupt occurs in the first cycle of a multi-cylce ALU operation instruction that immediately follows another ALU operation instruction, then the instruction will be skipped and not executed.
Place a NOP instruction between the two ALU instructions This has been implemented in both our OCCAM and C compilers as a command line option.
Note the workaround should be included in any hand written assembler code.
Block Move Performance Issue
When using the move instruction to transfer data between internal and external memory, the memory system will not allow the read and write accesses to be interleaved. This means that each access to the internal RAM made by the move operation will take two cycles and to the external RAM three cycles (more for slower memory).
Analysing high priority processes
If the machine is running a high priority process before being
analysed and the device is wired to boot from link, not ROM,
then the machine will resume execution of that high priority
process as soon as it is released from analyse. The Wptr will
also be set back to MemStart. This will cause the machine to
crash, there is no workaround.
Reboot Instruction Problem
The symptom is that the reboot instruction deadlocks a boot from link processor if it is executed at High Priority. Therefore don't use reboot instruction from high priority.
Erroneous address during RAS time for 16/8 bit accesses
An erroneous address may appear during the first cycle of RAS time whenever a multi-access transaction includes an excursion into a precharge state, for example, if a series of 8-bit accesses are interrupted by a refresh.
The solution is to program the ShiftAmount for all banks with the same value. Memory banks consisting of SRAM only will not be affected by the ShiftAmount value as it is not used unless RAS time is non zero anyway.
Trap enables word
This register contains the word which encodes the trap enable and global interrupt masks. This should be ANDed with the existing masks to allow the trap handler to disable various events while it runs. However, currently the trap enables word overwrites the existing enables. With this implementation a trap must disable all other trap groups to ensure correct execution, this increases the difficulty of writing nested trap handlers.
data drive delay incorrect near bank switches
If an access to one bank of external memory is immediately followed by an access to a different bank then the data drive delay settings for the second access may be used for the first access.
The solution is to program the DataDriveDelay for all banks with the same value.
STSHADOW Instruction Corrupts Stack.
The problem affects to storing of low priority registers from with a high priority process using stshadow. The operation appears to save the registers to memory correctly, but in the process corrupts the value of the A and B registers currently on the stack. This really only has implications for users wanting to use a software real time operating system.
Use a LDSHADOW instruction immediately after the STSHADOW instruction to correct the stack.
Storing of low priority registers from within a high priority process using stshadow.
The operation does not save the low priority trap enables bits in the enables word, however the micro-interrupt enables are correctly saved. Implications are for users wanting to use software real time operating systems.
Aborting of external Outbyte/Outword fails
Problem:
If a microcode interrupt occurs during an OutWord or OutByte to an external channel then the instruction may be re-started incorrectly. As a result the wrong data will be sent on the OS-Link.
Workaround:
Use the Out instruction instead with a byte count of one or four.
EventReq Pin is Level Sensitive
The EventReq pin should be positive edge sensitive to signal that an external event has occurred and requires an event channel communication to take place. However the pin appears to be level sensitve and will cause multiple event channel requests to be made while the pin is held high.
The reboot instruction should initialize both Trap and GlobalInterrupt enables. It does in fact leave them both unchanged.
Workaround is to disable all interrupts at the interrupt controller and initialize the global enables while running in high priority before issuing the reboot instruction.
Description: When an Out instruction is executed on a channel which has a waiting alternative process on it, it deschedules the out process and schedules the alting process. This works fine. The problem occurs if the scheduling operation is trapped. At the point when the trap is taken the current IPtr has been written to memory but the status_valid bit has not been reset. Thus on TrapRet the outputting process bursts back into life instead of being descheduled. This breaks process synchronisation and a crash occurs some time later.
Workaround: The software workaround for this bug is for the trap handler to reset the status_valid bit (MSBit of Status word in the TrappedStatus location) before performing the TrapRet. The problem is that the trap handler must identify this failure case. This is relatively easy because the trap handler can first check that the trap reason is InternalChannel, and then test the pw.state word of the process being scheduled to see if it is Ready_p. If these conditions are true then the Trapped status_valid must be reset before TrapRet.
TRet fails to restart interrupted TimerInsert
Because Timer Interrupts rank above return from microinterrupts in the interrupt arbiter ranking (and also because trap handlers may manipulate timer queues) the status register of any trap return context must be tagged to ensure that, if the interrupted context was a timer queue insert, timer queue insertion is restarted from the front of the timer queue.
This force-timer-insert-restart function was ommited from the TRET ucode (but included for iret etc.)
Without this restart the returning process will attempt to continue searching the timer queue from where it was interrupted; this process may no longer be in the queue, the queue may have been modified or worse still a new timer queue may have been substituted by the trap handler or a subsequent interrupt handler. If this is the case then the processor may hang or the process may never be woken by the timer.
The workaround for this bug is to ensure that trap and interrupt handlers do not modify the timer queues in any way - or if they do they should manually test the trapped status register value and if it indicates an interrupted timer operation (01000, 01010 or 01011) then the status value should be modified to indicate the restarting version of the interrupted operation (set bit 26 of the Trapped StatusReg) restart value.
Incorrect order of boundary-scan chain
Due to an error in the boundary-scan logic, EventWaiting effectively does not have a boundary-scan cell.
The consequence being that EXTEST will no longer function correctly for the EventWaiting pin.
Revised boundary scan description language (BSDL) is available.
Peek and Poke OS-Link Commands use Memstart Memory location
This is not strictly a bug but is part of the silicon specification that needs to be documented to avoid confusion. The peek and poke commands are implemented in the CPU microcode. As the only way that the CPU can access the os-link read data is via memory, the CPU tells the os-link to store this data in the internal memory at memstart (#80000140). This will obviously cause data stored at addresses #80000140 to #80000147 to be overwritten.
If an internal memory tester or dump utility is required then it needs to be aware that these two locations are not accessable if peeking and poking is used to access memory. On the ST20450A device which has an internal RAM disabling feature, the RAM must not be disabled when booting from link because the EMI may not be configured and hence the CPU will not be able to access the oslink read data.
Illegal configuration for EMI strobes
If any strobe is configured with edge times of: e1time = 0, e2time = ((castime cycles *2) - 1) phases, that strobe will behave erroneously when back to back memory accesses occur.
Do not use this particular configuration.
DIV and REM Instructions Bug
The div and rem instructions do not work if the dividend is negative and the divisor divides into the dividend exactly, unless the divisor is an exact power of 2.
The workaround is to replace each div and rem instruction with a code sequence that first checks the sign of the dividend and if negative, flips the sign, performs the divide and then flips the sign of the result.
This is implemented in the toolset compilers and the user does not need to worry about it, unless they are writing there own assembler code using these instructions.
Timer Scheduler Trap Bug
When a scheduler trap is set the priority of the scheduler event should be stored in the scheduler trap priority field of the StatusRegister. In the case of timer scheduler trap this fails - the priority is always recorded as High.
This results in the wrong trap handler being executed, which is fatal if there is no high priority scheduler trap handler installed.
Therefore avoid using timer scheduler traps.
Disable external micro-interrupt requests
There are four possible combinations of enable/disable for high and low priority micro-interrupts, however only three are supported.
It is not recommended to disable high priority micro-interrupts with low priority interrupts enabled. With this combination it is possible for high priority external events that are apparently disabled to be accepted as low priority transactions.
Use of Semaphores in interrupt handlers
in and out instructions, at their interrupt points have to maintain 4 words of data: - the source, destination and count values of the ongoing block move + the wdesc of the process to be scheduled at the end of the move. The move data is stored in a,b,c (as in block move) and the wdesc is placed in the "shadowed1reg".
if an interrupt (at the same priority as the channel comms) occurs then a,b,c are saved by the microcode but shadowed1 *isn't*
the semaphore signal instruction also uses shadowed1 register. So that if it executes then: on return to the in/out instruction the wdesc to reschedule is corrupted.
Using stshadow and ldshadow instructions on entry and exit to the handler to cause shadowed1reg to be preserved cures the problem.
Use of st/ldshadow is a workaraound - though it probably adds
13 cycles to handler entry and 17 to exit.
Alternatively the problem can be avoided by resticting use of certain code/mechanism - e.g. not doing semaphores in an interrupt handler at the same priority as any process that can do channel communication.
Note that there is *no* problem over high priority interrupts interrupting low priority communication. Also there is no problem if in a high->low priority communication then the high priority end deschedules before an interrupt occurs - this may be the case in a system where a high pri interrupt hands off to a high pri process which immediately will set up the communication of data to a low pri process.
POSTNORMSN instruction
C4 Core - Bug in POSTNORMSN Instruction
(This affects all C4 core products !)
Single length floating point code is unreliable in the presence of (micro-)interrupts.
What appears to be happening is that the POSTNORMSN instruction when interrupted restores the a,b,c registers to their original values but then does NOT re-execute.
The "fast" single length floating point code should not be used on C4. (This is the fp code written in assembler which uses unpacksn, postnorms and roundsn). The "slow" code (written purely in occam - at least it used to be - may be C now) will be safe as postnormsn is not generated by the compiler. Similarily double length FP is safe.
Also note that this bug is limited to the C4 and will not affect the C2.
Use the "slow" single length fp library.
OS-Link Data Corruption
ST20450 OS-Link Data corruption ( This is particular to ST20450 only)
Data received by a low priority process from another T450 via an OS-Link can be corrupted when there is a high priority process which performs an operation that saturates the internal SRAM memory (such as a block move to internal memory)
The problem does not occur if the block move and link are using external memory. This is because external memory is sufficiently slow that the block move has stall cycles while it is waiting for read data to return and in these cycles the link engine can get a request across to the memory controller. Once the request reaches the memory controller then priority is ignored so the low priority link access just goes through into the queue with the hi priority block move accesses.
So in summary: a channel input from a hard channel at low priority to a buffer in internal memory is unreliable if high priority activity can saturate access to the internal memory for any significant length of time (just over 100 cycles seems the limit on a 40MHz part).
Given that memory saturation is difficult to predict then the safest rule is that low priority process should never do an input from a hard channel(OS-Link) to a buffer in on-chip memory.
END OF BUG LIST