First I would suggest searching this forum for "MCF54418" and for "slew". There are lots of posts matching these, but nothing obviously matching your problem.
You may find a few posts mentioning problems with the Reference Manuals. You should get Rev 3 and Rev 4 (the one currently available). There's something wrong with the DMA chapter in the latest one, so you have to read that chapter in the previous one. There are likely to be other uncorrected problems with the manual. This problem has never been fixed, and there's been no Errata issued that mentions this or any other problems.
So I wouldn't trust the Slew Rate Table to be accurate.
So either you can't set the slew rates of those pins, or you can, but the documentation is wrong.
Unless you can get one of the designers to answer this, or find someone who has had this problem before, you're going to have to reverse-engineer the chip yourself.
If you can set up a test where you are driving those pins and can measure the resulting slew rate with an oscilloscope, I'd suggest sequentially changing all 22 slew rate control registers. The pins will either change their slew or they won't.
> The default rise/falling time is 200ns, that is too slow.
In what way is 200ns "too slow"? If you're using them for their SDPI function, then these aren't the clock or data pins. These are the chip-select pins. As long as there is at least 200ns between chip-select assertion and the clock changing, then the SPI transfer should work fine.
The DSPI Specifications listed in "40.1.3 Features" includes "PCS to SCLK delay" and "SCLK to PCS delay", so you should be able to set those to handle the slow slew rate on the slower PCS pins.
In case you think that adding that extra delay is going to slow down the maximum transfer rate, then I've got news for you. These DSPI modules seldom run at the "maximum theoretical rate" implied by the clock rate anyway. They have lots of internal processing delays that show up as unexpected gaps between the data transfers. Any extra PCS delay will be lost in that.
If you're using them as GPIO pins, then how is 200ns "too slow". These aren't RGPIO pins, so the time it takes for the CPU to change these pins may be a lot longer than you expect, possible 20 CPU clocks or more.
Tom
