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
"when i program my code it works properly (answer my ping)"
What, exactly, do you mean by, "program my code"?
Do you mean downloading it via JTAG, and then starting it with the debugger?
"but when i turn it off and on (reset) it doesn't answer my ping !"
So there's something wrong with the Reset in your system!
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...
yes i download via jtag , no i don't debug .
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
Time to break out the debugger, output some diagnostic messages, and eliminate a latent defect in your code as the cause.
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.
OK - so proceed from there!
Can you reproduce the issue with the debugger connected?
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?
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 !
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.
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!
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.
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.....
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 .
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...
View all questions in Keil forum