SGS-THOMSON Microelectronics
ST20450A Customer Bug List
Compiled by Ian Griffin
ST20 Technical Marketing
Created on : November 18, 1996
Last Revised on :
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.
Workarounds
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.
************ Interrupt of multicycle ALU function causes function to be skipped *****
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.
Software Workaround
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 takes extra cycles when moving between int and ext memory ******
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).
***** Analyse/REBOOT opcode from hi-priority fail when booting from link*****
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 se
t 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 stac
k. 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 and not edge sensitive ***********
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 mad
e 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 co
ntext 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 substitu
ted 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.
Software Work Around :
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 commands overwrite upto two words of internal RAM****
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 c
ause 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.