Experience with SAK82C900 TwinCAN device on the LxNET50 dev kit?

Hi All Didn’t get any response with this post on the development board list so here goes again… just in case any CAN guru’s out there only look at the NET+50 list :wink: I’ve got a LxNET50 dev kit which has a Infineon SAK82C900 TwinCAN device as a 8-bit memory mapped peripheral using a multiplexed address/data bus via glue logic and buffering… The kit has no driver for the device… and even if it did, I’m not using Linux on the board… so I’m writing my own… However, the CAN device has a very strange scheme for accessing its internal registers: 1) The device is paged (No real problem) 2) The CAN RAM areas of the memory map need either very long gaps between accesses (not possible via the NET+50 chip select configuration as no way to insert post cycle null periods) or in the case of reads n + 1 short reads to get n bytes of real data… with each read being the real data for the access immediately before… This scheme is implemented on the device to stop RAM access clashes between the CAN controllers and the external memory interface… Inter write null periods can be achieved in software by breaking the write up into byte slices in code and inserting NOPs after each individual write… The reading of the CAN RAM register should also be easy… However, I can not find a reliable general purpose method for reading a given 32-bit register as simply reading addresses n, n+1, n+2, n+3, n+4 and using the last four bytes (swapping byte order for endian mode accordingly) does not always work. This is because some ram registers have non-ram register after them in the memory map and so the read n+4 gives the first byte of the non-RAM register… Also the memory interface is very flakey and it appears every so often the SAK82C900 internal buffering logic doesn’t update the internal address and so the next read gives the data for the read two accesses ago and not the one immediately before… This causes read-modify-write operations to shaft the state of the registers… bang… code asserts… Being more of a hardware engineer, and having simulated the memory control logic to test timing etc, I suspect my code is driving the device badly and the flakiness in the reads is a result/side effect… Anyone got any experience with this device? and even better the one on the LxNET50 board? Any help you could give would be most appreciated… Thanks Dave

Hi Dave, > I can not find a reliable general purpose method for > reading a given 32-bit register as simply reading > addresses n, n+1, n+2, n+3, n+4 and using the last four > bytes (swapping byte order for endian mode accordingly) > does not always work. This is because some ram > registers have non-ram register after them in the > memory map and so the read n+4 gives the first byte of > the non-RAM register… I’m doing the same and it works correctly. Are you shure that you enabled SHORTACCESS in the global control register ? If you forget to do this, then only CANRAM registers will have old values. If you enable this you will get previous value for all accesses. > … Also the memory interface is very flakey and it > appears every so often the SAK82C900 internal buffering > logic doesn’t update the internal address and so the > next read gives the data for the read two accesses ago > and not the one immediately before… This causes read->modify-write operations to shaft the state of the >registers… bang… code asserts… This is a known bug in the FS-Forth Lattice isp2032. You need an update for the 2032, then it will work. As Software workaround you can read every register five times before the real access. Jochen

Found my problem… its the glue logic… CAN_ALE appears to need holding high for two bus clock periods instead of one to account for the setup time of the bus buffering… This is very strange as all the data sheets point to one BCLK clock period (~22ns) being more than sufficient to account for the 5ns min. address setup time of the CAN device and the 10ns setup time of the bus buffer device… ho hum! BBFN Dave

Hi Jochen, > > I can not find a reliable general purpose method > > for reading a given 32-bit register as simply reading > > addresses n, n+1, n+2, n+3, n+4 and using the last > > four bytes (swapping byte order for endian mode > > accordingly) does not always work. This is because > > some ram registers have non-ram register after them > > in the memory map and so the read n+4 gives the first > > byte of the non-RAM register… > > I’m doing the same and it works correctly. Are you > sure that you enabled SHORTACCESS in the global > control register ? If you forget to do this, then > only CANRAM registers will have old values. > If you enable this you will get previous value for all > accesses. > I have the LAE bit set to 0… which the UM claims is short access mode… Is this correct or should I have it set the other way around?.. How can you use a fixed wait state configuration when the data changes part way through the cycle? > > … Also the memory interface is very flakey and it > > appears every so often the SAK82C900 internal > > buffering logic doesn’t update the internal > > address and so the next read gives the data for the > > read two accesses ago and not the one immediately > > before… This causes read->modify-write operations > > to shaft the state of the registers… bang… code > > asserts… > > This is a known bug in the FS-Forth Lattice isp2032. > You need an update for the 2032, then it will work. > As Software workaround you can read every register > five times before the real access. I presumed this bug was to do with the glue logic not holding the address for the 10ns minimum required after CAN_ALE -> low… I’d already spotted this one and I’d hoped I’d fixed the interface problems (see the VHDL for the can logic attached)… I also made the CAN_RDY signal available at the micro… with some mods to the dev board… so I could see if the device ever went into a not ready state… BTW I should have said before… I have my own HW design with the CAN device as well… I’m only using the FS-Forth kit to write my drivers as a way of eliminating HAW problems with my design… and the CAN_RDY line isn’t able to extend the bus cycle as the bus signals required, although available on the LxNET board, are not available on my real HW design :frowning: … I’ve attached my CAN device utility code… any chance you could look it over? Regards, Dave