Alban wrote:
Deleting the whole thread instead of correcting one post was a mistake "we" recognize/acknowledge.
Still, as this new thread proves, no problem is being buried !
Fortunately enough, I dunno what NTB means, but I'll have a look !
Sorry you took it this way, I hope now you have a better opinion of "their company"

Thanks, that is what I wanted to know... Whether FSL acknowledged the mistake of deleting the whole thread.
Look up the word "
insult" in the dictionary;
Any person saying basically, "I don't like you because...", on the companies own public forum could be considered insulting, unless they word it very carefully. Anything indicating that the company treats customers with lack of respect can "affect offensively or damagingly". About the meaning of, NTB, to me it's an indirect way of saying "not too bright" because there are so many possible meanings of the acronym.
I want to clarify the way I took it. I did not feel that FSL was only trying to "bury" the issue. What offends me is when "technical support" assumes I am guilty of being incorrect (ignorant)
before investigating my issue, while at the same time giving me the impression they have
much less understanding of the issue than I do.
- The support folks have a bad habit of blowing off my requests with a dumb explanation like "I don't see your problem" and closing it.
- They assumed me to be the other SCI thread in the forum which had been replied to, and closed the SR. It wasn't even the same problem I described. They made a strange comment, "I can not comment on why your peers might ignore your posts". I suppose they misunderstood my question why FSL didn't respond to my forum posting past 3 days.
- They assume I don't know how to use SCI (I definitely did not indicate I was a novice).
- I asked about the documents for DP256C leading to "DP256B" errata links, and they had to get back with me on whether that was an error (the explanation made sense though).
- Along the way, they kept stating how they don't even make the bad mask set anymore... What's that got to do with my issue? And still, do they think nobody uses it right after they stop making it?
- What got me most was when they suggested I probably was not clearing my interrupt flags correctly. Uuuuh... so my ISR is not being called because the interrupt flag is staying on. I thought, "how competent is this guy". Sure, he probably just wasn't focused on the issue I kept describing. It's hard for one to think practical after deciding one is dealing with ignorance. At least they made a good suggestion to set HPRIO which sped up the SCI1 response more than I thought it would. It reduced OR incidents, just a way of not using OR since I couldn't get it to work right.
- I think my worst problem was that I had recently destroyed the only 2K79X that I could find, so only had the ones left with the known errata. I just wanted them to try something more similar to my asynchronous scenario using one of their DP256C-2K79X. When I finally found a replacement, however, I could not duplicate the exact problem I saw where the ISR was not being called. Instead, I learned that less often, the OR was setting without RDRF, which was undocumented because I had an older document revision.
I blame my hot opinions on other companies more. My failing patience was not triggered by FSL. I've been left overwhelmed from previous experiences. FSL has resolved more issues than many other companies or individuals. With FSL I did feel less offended after the screening stage. It's the sort of problem where support personnel seem to be typing keywords in a search engine and pasting the textbook answer for reply. This system only works for others who have not even read documentation. My questions were not textbook questions, and I've taken it as
insulting my intelligence.