hi all
I've worked with tcp library with 4.2 version without any problem
now i switched to 4.7 version
when i program my code it works properly (answer my ping)
but when i turn it off and on (reset) it doesn't answer my ping !
thank
As suggested earlier: "It is entirely possible that your hardware is flawed, and you've just been "lucky" to get away with it so far..."
So, aparently, it was the software that was (and still is) flawed - not (just) the hardware!
"i add a short delay in initial"
That's a poor approach - as it leaves you open to exactly the same thing happening again!
You really should try to find some positive status indication from the MAC to confirm when it is truly ready.
Relying on arbitrary delays is, as you've seen, a recipe for disaster...
hi again
well i found the problem ;-) when i restarted my board by reset pin it works again (answer my ping) so i guess it must have caused by power stability but not for my processor but for mac chip in simple word the mac chip needs more time to be stable . so i add a short delay in initial . i guess the new version start up file run faster than privies version .
thank for your answers .
there is enough capacity (memory and pin)
but the main problem is this that there is no access to tcp library source
so it isn't matter using debugger or use pin or printf.....
Yes. Only the 10 million/year product should go for perfect fit. But that is probably a lamp timer where you know _exactly_ what it must fulfill.
Real products normally requires a 1.1 spin, after the customers notices that the original specification was good, but a competitor did something else. Or the customer (or whoever is the product owner) just forgot something.
Without safety margin in the original design, there will be no spare space to solve these requirements changes. If then is the biggest chip in the family, then it can require a full redesign of both software or hardware. Just for that lapse in requirements specifications.
One client worked on the principle that, if your system doesn't have enough resources (memory, time, pins, whatever) to dedicate 10% to "diagnostics" - then it just doesn't have enough resources!
It seems a fine principle to me!
I very seldom use a debugger.
Most times, I settle for asserts and suitable printouts.
When something doesn't work, it is almost always possible to just read the code, predict the behaviour and then add specific instrumentation to prove the assumption before the problem is fixed and fix tested.
So it helps to have a processor with some extra code space to allow extra instrumentation in special debug builds for some extra printouts.
But it really is preferable if the live hardware have capacity enough to also contain defensive code, looking for unexpected states and then performing some recover actions or maybe full resets.
After all, code should be written for staying up and running for years - basically until next time there is a power loss or someone decides to upgrade the firmware with some new functionality.
thank u
So you'll have to use other tools & methods - like printf to a serial port, lighting LEDs to indicate progress in the code, etc, etc,...
.
it's not a simple code to use printf or led it's just call main_TcpNet ();
and if u mean to check run system i did it
i set high one pin in my code and it works.
Do you have a Dev Kit or similar which works? If so, compare and contrast...
I've mentioned that this board works without any problem with Previous version of keil
It's your system: You have the code in front of you; You have the hardware in front of you. Nobody else has this, nor knows anything about your system -
i know all of these
therefore, you are the one who needs to get in there and get debugging
it's a bit hard to debugging tcp library !
when i debug and put the debug in run mod it works again
and answer my ping !!
i connected the reset out pin to the mac chip reset
is it may related to this problem ?
but this pin isn't depend on code ,is it?
OK - so proceed from there!
Can you reproduce the issue with the debugger connected?
i'm sure of my hardware and i don't think the problem is reset because i set high one pin in my code and it works.
What, exactly, do you mean by "tested"?
i mentioned i have some code with a keil v4.2 that work with my hardware without any problem.
Time to break out the debugger, output some diagnostic messages, and eliminate a latent defect in your code as the cause.
Do you mean downloading it via JTAG, and then starting it with the debugger?
yes i download via jtag , no i don't debug .
So there's something wrong with the Reset in your system!
if u mean my hardware my hardware is OK I've already tested it with other code .
but if u mean software it's a simple code that i use from keil sample .
when you just turn off & on, it's all down to your system to apply proper reset conditions...
as i knew it's startup file job
Thank
"when i program my code it works properly (answer my ping)"
What, exactly, do you mean by, "program my code"?
"but when i turn it off and on (reset) it doesn't answer my ping !"
When you download and/or start your code via JTAG, the JTAG resets the processor; when you just turn off & on, it's all down to your system to apply proper reset conditions...
View all questions in Keil forum